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ABSTRACT 



The United States Navy lacks the proper and efficient 
tools to evaluate/predict the performance of computer 
systems during the early design phases of system 
development. This thesis applies state of the art techniques 
to provide a methodology that can assist in the 
evaluation/prediction process for Naval fire control 
systems. The computer system evaluated is a part of a 
modular addition to existing shipboard gun fire control 
systems. A contract for the Engineering Development (ED) 
phase of the program has recently been awarded to industry. 
The computer system architecture is evaluated utilizing a 
Petri-Net simulation which is best suited to the purpose of 
concurrent computer system performance prediction. The 
prediction model, described herein, accomplishes the 
evaluation with the results being utilized to recommend 
possible performance improvements in the hardware and 
software to the U.S.Navy Program Office. 
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I . INTRODUCTION 



A. BACKGROUND 

The fire control system evaluated, the SEAFIRE pro,?ram, 
is presently in the Engineering Development (ED) phase of 
the weapon system development process with system deployment 
expected some time during the mid 1980's. A Request For 
Proposal (RFF) for the design of the system was released to 
industry and was responded to hy a number of contractor 
teams. A thorough evaluation of these proposals, which 
included technical, management, cost and schedule factors, 
was performed over a ten month period resulting in contract 
award to industry during 1979. The contractor, although 
provided an AN/UYK-20 computer as a baseline processor, was 
not prohibited from using additional imbedded processors to 
support/enhance his design. The AN/UYK-23, being a standard 
Navy computer, was required for use in the SEAFIRE system at 
this time. The Program Office, however, has plans to replace 
the AN/UYK-20 with a modern computer prior to the SEAFIRE 
fleet introduction. These plans though will only be 
implemented if the AN/UYK-20 is replaced as one of the Navy 
standard computers and if the Naval Material Command allows 
it to occur. 

The computer architecture, as designed by the 
contractor, represents an untested real time combat 
subsystem. This thesis attempts to evaluate the SEAFIRE 
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computer architecture and provide a meaningful input to the 
U. S. Navy SEAFIRE program office (Naval Sea Systems 
Command) as to its predicted performance. 

3. APPROACH' 

The first step to accomplishing this goal was to become 
familiar with the present design status of the computer 
architecture and to develop liason with its designer. The 
present level of the design drove the evaluation to a 
modular configuration, as would be expected at this point in 
the design process. A determination was then made to 
establish the performance measures on which to measure or 
estimate the performance of the system. 

The next step was to research a number of available 
methodologies for computer architecture performance 
prediction and to select the one methodology determined best 
suited for this project. The model selected was designed by 
L.A. Cox, based on work led by J. Dennis at M.I.T. and other 
researchers. This model was developed to execute on a non 
standard CDC-7600 computer system and thus required 
considerable effort in program modification to enable it to 
run on the PDP-11/50 minicomputer at NPS. 

The remaining work consisted of developing program 
representations of the SEAFIRE software and hardware for use 
in the simulator, and finally in the analysis of the 
results. A number of assumptions, which were required due to 
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a lack of information, are denoted throughout this thesis. A 
listing of the final version of the Petri-Net simulator is 
contained in Appendix A. 
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II. THE COMPUTER SYSTEM ARCHITECT 



A. INTRODUCTION 

How does the computer system architect cope with the 
rapid pace of computer technology? His capability to 
describe the hardware at specified levels in an efficient, 
interactive manner that provides a dynamic atmosphere during 
the life of computer design may be the key. This chapter 
deals with a spectrum of design techniques that assist the 
archi tec t . 

B. COMPUTER SYSTEM ORGANIZATIONAL LEVELS 

According to Doty and Liposki (11) Von Neumann's 1946 
paper, "Preliminary Discussion of the Logical Design of an 
Electronic Computing Instrument" is fundamentally one of the 
most significant papers in computer architecture written? 
principally because it was written 15 years before the term 
was coined (Von Neumann claimed no ideas but was merely a 
focal point for them). This paper outlined the four 
principle units required of a general computing system? the 
control unit, the data operator, the memory, and the input/ 
output unit. These units form the conceptual basis of almost 
all current computers. 

What is computer architecture? By "computer 
architecture" we mean the abstract, functional description 
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of a computer as seen by a machine-level programmer, that 
is, everything the programmer needs to know to write 
programs that run effectively on the computer (i.e., the 
conceptual structure and functional behavior, as distinct 
from the organization of the data flow and controls, the 
logical design, and the physical implementation). As a 
result of the changing technologies of processors and 
memories, deficiencies in earlier designs, as well as 
innovations in networks and distributed processing, computer 
architecture is evolving rapidly. 

In addition to technology, there are several other key 
factors that contribute to architectural innovation* most 
significant are increasingly inexpensive hardware and the 
rising cost of software (human labor). All future systems 
should be designed with consideration of these and other 
facto rs . 

A good system can be defined as a well-organized 
collection of components chosen to meet the system goal. A 
modular system is a collection of these component modules. 
The systems are the largest design units, and subsystems are 
convenient intermediate-level complexes ( 18 ). 

One system's components may be another's systems, in 
different situations. Therefore, a complex system design 
should be described at a number of different levels which 
may change dynamically as the design proceeds from concept 
to Implementation. 
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1 . L:evels of Hardware Design 



Bell 


and Newell (2) 


define the 


levels in 


the 


hierarchy of 


digital computer 


struc tures 


largely on 


the 



basis of considering the different activities of different 
technical practitioners. The 'institutional positions' of 
logic designers and circuit designers are used as evidence 
for the existence of distinct levels. Their highest level 
(the PMS-Processor Memory System level) has computers as 
structures and processors, memories (storage) etc., as 
components. The next, or programming level, sees programs as 
made of component instructions, operators, etc. The three 
logic design levels are the: 

1) Register Transfer Level - arithmetic units made from 
registers, controls, data operators? 

2) Sequential Switching Circuit Level - counters made 
from flipflops, latches; 

3) Combinatorial Switching Circuit Level - encoders, 
selectors, iterative nets made from logic gates. 

The lowest level they consider is the circuit level 
where example systems (circuits) are amplifiers, clocks and 
gates and where the components include relays, transistors, 
resistors, diodes and delays. The essential constraints for 
the notations to satisfy are ones of completeness, 
flexibility and brevity ( high informational density) (3). 

An appropriate criterion might be to identify a level of 
design with a design description (specification) then: 
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”a system level ... is characterized "by a distinct 
specification for representing the system (that is, the 
components modes of combination and laws of behavior). These 
distinct languages reflect special properties of the types 
of components and of the way they combine . . . The fact 
that the languages are highly distinct makes it possi,ble to 
be confident about the existence of different levels’ (2) 

This method of identifying the various levels of system 
design allows one to identify the most recently emerged 
levels, but it leads to a significant difficulty. Whenever 
it is difficult to decide whether two languages are highly 
distinct, it is also difficult to decide whether they define 
different levels. Thus it seems as though there are no 
effective procedures, even in principle, for counting the 
number of distinct levels of system design. The number of 
levels, and thus the extent or depth of the levels, are 
difficult to precisely determine. 

This view introduces a new notion: the span (depth) of a 
level is commensurate with the short term comprehension of a 
human being. That is, one historical reason for designing a 
large system in successive stages has been that the human 
designer has a certain limit to the range of detailed 
consideration which he can instantaneously handle 
effectively (although Cray/Amhdahl developed computers 
individually). If the design process is to be automated, it 
might be initially done in smaller steps _than humans 
currently handle (for the machines are notoriously inept at 
handling the intuitive associations which a designer 
employs) . The number and span of the design steps has always 
been difficult to precisely determine and we should expect 
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them to continue to change in the future (18). I 
important to remember that all our experience to date s 
that design automation cannot rely too much on artifi 
methods; the human has to stay involved. 

The design specification is the key to the defiaitio 
a level. The language defines the level; is the tool 
designing at that level; expresses the components 
systems of the level; and provides the documentation 
design at that level. The lowest-level, irreducible unit 
a design are the primitives (words) of the language; 
system structures designed at that level are the sente 
of the language. Preparing a design at a given level m 
writing a statement in the language of the level, 
process of designing an entire system becomes a proces 
carefully translating statements in one higher-1 
language to successively lower levels. 
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C. COMPUTER HARDWARE DESCRIPTION LANGUAGES 



Computer hardware description languages (CEDL's) can be 
defined as languages for describing, documenting, 
simulating, and synthesizing digital systems with the aid of 
a computer (23). A CHDL can be used to describe the logic 
gates, the sequential machines, and the functional modules, 
along with their interconnection and their control, in a 
variation of a programming language tuned to the overall 
needs of describing hardware. 

1 . Design Automation 

Just as software designers use high-level languages to 

I 

express algorithms in terms of language statements, so 
digital hardware designers are beginning to use hardware 
description languages to describe the digital systems they 
want to design (24) . 

The task of designing a digital hardware system can be 
considered as consisting of the following steps: 

1) The generation of a system diagram from the 
specifications of the system to be designed. 

2) The production of detailed logic diagrams for each 
subsystem. 

3) The partitioning of the logic diagram into general 
units . 
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4) The assignment of integrated circuit chips for 
implementing each unit. 

5) The placing of chips on logic cards and of cards on 
hoards, and 

6) The interconnecting of the chips. 

7) The testing of the integrated circuit hoards. 

Computers have been widely used for aiding steps 4 to 7. 

A total design automation system requires that steps l.to 6 
be automated. CHDL's can be used for aiding system and logic 
design as well as partitioning a digital system. A designer 
can use a CHDL to express his design and leave the exacting, 
tedious, uninteresting details to a computer (23). 

The process of automated logic design may consist of 
the following steps: 

1) A designer expresses his design in a CHDL by writing 
a program. 

2) A hardware compiler (translator) checks the syntax, 
consistency, etc. of the language statements and reports the 
errors to the designer for correction. After the errors are 
corrected, the translator produces a data base to be used by 
the system simulator and the logic synthesizer. 

3) The system simulator models the design at the system 
level. This will save the large amount of computing time 
used for simulating everything at the detailed gate level. 
If the system performance is unsatisfactory, the design 
language statements are modified. If the performance is 
satisfactory, the next step is taken. 
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4) The logic synthesizer (a program) uses the data base 
produced hy the translator, accepts the types and 
constraints of logic components, and produces a logic 
diagram . 

Since a CHDL constitutes the input to the design 
automation process, it plays an important role in the task 
of achieving automated logic and system design. 



2 . Digital Hardware Languages Under Develonment 



A number of digital hardware languages exist today and 
are in use by industry as well government sources. One of 
the most recent uses in the military was for the selection 
of the Computer Family Architecture (CFA) (1,20). This was a 
joint DOD effort aimed at providing defense systems 
developers with a software compatible family of military 
computers at varied levels of performance that have 
extensive systems/support hardware. One facet of the 
selection process was that the measurements and tests of 
hardware candidates were made, not on the various computers 
as physical objects, but on their formal descriptions 
expressed in IS?L (Instruction Set Processor Language) (2). 

This was the first time that the architectures of 
commercially viable computers were described in a formal 
language, the description compiled, and then used to drive a 
simulator, executing benchmarks and diagnostic machine 
language programs. A valid sign for future users is that it 
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was generally accepted by industry, military and government. 

What other methods have been developed since the above? 
The remainder of this section covers several of the efforts 
presently being developed as a result of the Working Group 
of the Conference on Computer Hardware Cescription 
Languages. 

a. Consensus Language (CONLAN) 

CONLAN is a consensus hardware description language 
capable of representing hardware at several distinct levels 
of detail (15). The range of language levels suggests a 
family of languages that share a common basic syntax and are 
rooted in a common semantic base. 

Guidelines laid down for the language follow: 

A. CCNLAN must support design, description, 

{ 

and simulation of at least the following classes of systems: 
gate networks, register networks, processors, memories, 
processor systems. Each class has been fully defined. 

B. Any system may be displayed via either (a) a 
network structure description or (b) a behavior description. 

C. CONLAN is to service: 

1. Computer architects and logic designers 
for purposes of trade-off exploration and 
optimization, design verification, and 
design documentation. 

2. Systems, micro, and applications program- 
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mers . 



3. Electronics production engineers. 

4. Maintenance engineers. 

D. CONLAN syntax and semantics must support: 

1. Well-defined descriptions 

2. Machine parsing, interpretation and 
simulation with error detection (strong 
typing has been adopted) 

3. Comprehension of complex system structure 
and function 

4. Division of design efforts 

5. Control over the level of abstraction at 
which subsystems are described. 

6. Simulation control 

E. COt^LAN will be evaluated in terms of 

benchmarks such as: standard function declarations, time 

operator declarations, integrated circuit descriptions (long 
list, including microprocessors), design descriptions 
(another long list including a multiprocessor system). 

The details of CONLAN (i.e. BNE grammer, etc.) are 
contained in (15). Since CONLAN is still under development, 
additional information is available only from the working 
committee which is developing the language. 

b. Digital Design Language Translator (DDLTRN) 

Today, the greater complexity of systems, the desire for 
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short design cycles and error-free designs, and the use of 
array logic all suggest the need for machine assistance in 
the logic design activity (8). DDL is a block oriented, 
statement register transfer language for the description of 
digital hardware. DDLTRN is a program that translates a DDL 
description of a digital system to Boolean equations and 
register transfer statements suitable for driving a 
companion simulator program DDLSIM (6,9). rDLTRN is written 
in the IFTP.AN (a structured FORTRAN) language (16). 
Translation consists of replacing the syntax of more 
abstract language constructs with more explicit syntax, 
yeilding Boolean equations and IF-THEN conditioned register 
transfer statements. 

As mentioned earlier, DDLSIM is a program for simulating 
digital systems described using DDL (7). DDLSIM does very 
extensive error checking of described systems, simulation 
control cards, (same system with different data sets and/or 
parameters), and the simulation process itself. DDLSIM 
permits multiple simulation runs within one job in order to 
either verify the system design or study its behaviors under 
different conditions. 



DDLTRN/SIM and CONLAN are two examples of the growing 
number of design/automation aids available today. These 
CHDLs put the the architecture community in the position to 
explore and develop needed design automation tools. Since 
Dietmeyer is a member of the above committee, it would be 
expected that many of his ideas will be incorporated into. 
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or provide the basic groundwork for future efforts. 

D. INTEGRATED CIRCUIT (IC) DESIGN 

Ever since integrated circuit designers began to put 
thousands of transistors onto a single chip, the cost, in 
terms of human labor, required to lay out the circuit has 
been extremely high. Although hardware has reached a point 
of being considerably cheaper than software, the Department 
of Defense (DOD) requirements for special purpose, limited 
market chips has seen its time. The need for good design 
automation in the area of integrated circuit layout is 
severe. What is needed, and what is evolving, are design 
techniques which free the designer from the tedious aspects 
of IC design and allow him to concentrate on the more 
creative and necessarily human side of the design process. 

Using traditional methods, large scale integrated 
circuit lay out is a tedious, time consuming and error-prone 
process. For commercial use, where literally millions of 
identical chips are sold each year, the cost to do this has 
not been a problem. But for the DOD it is becoming an 
Increasingly significant problem; especially since the DOD 
market for ICs comprises only about 7% of the total IC 
market and because environmental and other constraints are 
becoming more severe (16). The overall goal of an IC design 
is to pack as much circuity as possible into the smallest 
possible amount of "chip real-estate" ( IC density). 



22 



therefore, higher production yields may he obtained. 



1. The Problem and the Proposed Solution 



At present, when a company designs large scale 
systems, there are often delays of months or even years in 
the development of a prototype IC and the price for a single 
chip ranges from one quarter to half a million dollars, the 
DOD is forced to revert to using older technology. This, 
coupled with the typical eight to fourteen year system 
development cycle of large computer systems (examples 
include AZGIS, TACFIRE and CDC STAR 100), has created quite 
a military dilema. Add to these problems the stringent 
requirements for MIL-SPEC qualification, fault-tolerance, 
built-in test, high clock rates, and the use of advanced 
design concepts for affordability, causes the required chips 
not be ready for several years and when available are 
extremely high in cost to the user. 

A new DOD (Tri-Service) program known as Very High Speed 
Integrated Circuits (VHSICs) began at the start of FY 79 and 
is a six year effort initially budgeted for in excess of 
$200 million dollars. Program goals require a processing 
throughput capability for computers of between 130 to 1300 
times greater than presently exists. 

The overall purpose of the DOD program is to: 

. Advance introduction of VHSIC into military systems 
by at least five years ahead of present projections 
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. Focus industry attention on DOD reouirements through 
the establishment of distinct goals and funding infusion 

. Make the latest state-of-the-art devices available 
for military use in advance of commercial exploitation, 
thereby reversing the present two to five year lag between 
commercial development and military availability 

. Advance IC technology beyond the limits of optical 
litho- graphy to submicron dimensions 

. Replace over fifty or more present ICs with one IC, 
thereby providing at least a ten-fold reduction in the size, 
weight, power consumption and failure rate with accompanying 
savings in both initial and life cycle costs of present 
military computer processing systems. 

. Provide ICs with 100 times the processing throughput 
capability of present ICs (16). 

By meeting the above stated goals, the DOD expects to 
achieve affordable chips, reduce potential supply and 
logistics problems and maximize system reliability. The 
improved architectural and design concepts should result in 
a limited chip set with broad applicability to military 
systems . 



Can the Computer Architect Exploit this Advance? 



Despite these advances that semiconductor technology 
has created, the question arises as to whether the computer 
architect can exploit these with proven design methods of 
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his own. A number of approaches have been actively pursued 
over the last few years (see previous section). However, 
there are not currently the languages, operating systems and 
design methods needed to effectively employ the new LSI 
devices which can now be produced. We would like to be 
limited only by economic factors, not technical or 
theoretical factors. A hope is that a new dimension for the 
architecture of computer systems will emerge from these 
design methods so that LSI design methodology can be used 
effectively. There is a need to proceed slowly and rather 
cautiously and to introduce somewhat more general purpose 
description languages selectively. 

The military system cannot afford these time delays and 
much effort is being pursued to shorten this cycle and to 
obtain industry input earlier. A major directive. Office of 
Management and Budget Directive 0MB A:109 (17), has as a 
major goal, industry involvement in system development 
earlier in the conceptual development phase. This thrust, 
combined with the availability of the tools discussed in 
this section on design automation and those to be covered on 
architecture evaluation could be implemented as Concept 
Development Phase evaluation techniQues. The impact would be 
to provide state-of-the-art computer designs at lower costs 
with the added effect of shortening the entire 
development/procurement cycle. 
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E. SUMMARY 



This section has provided the basis to understand 
computer architecture as viewed by different practitioners 
and how methods are being developed to assist in early 
design phases. These techniques can assist the DOD in 
realizing better structured hardware and to accomplish the 
tasks recuired. 

The next section further defines the methodology phases 
of architecture evaluation used to enhance the automated 
design techniques covered. 



26 



Ill . COMPUTE?. PERFORMANCE EVALUATION 



A. INTRODUCTION 
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B. PURPOSES OF PERFORMANCE EVALUATION 



In general, there are three major motivations for 
performance evaluation: selection evaluation, performance 
prediction and performance monitoring. These purposes can he 
classified along several dimensions according to their 
specific objectives. As with many other system evaluation 
techniques, these classifications are only convenient ways 
of organizing a repertoire of knowledge in to a framework 
which can he more easily understood. The dividing lines 
between categories are somewhat unclear, hut are utilized 
for lack of a better method. 
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^ . _Selection Evaluation 



One of the most frequent reasons for initiating an 
evaluation is to include performance as a ’’decision 
criteria” in computer system or digital electronics system 
decisions for a specified operational requirement. The 
section on SEAFIRE provides a description of such a system 
along with an overview of the original evaluation guidelines 
for procurement of the system. It should he recognized that 
the computer system was only a subsystem in the context of 
the SEAFIRE hardware, which in turn was but a single factor 
in the total weapon system procurement (cost, management, 
etc. were also weighted as portions of system value). Each 
competitive contractor teams proposal may have contained one 
or more superior subsystems, but were judged to have fallen 
short in many other areas. For example, one of the losing 
contractors may have had a better computer subsystem, but 
poorer subsystems in the other areas. Additionally, his 
management approach or cost proposal may not have been as 
good as the winners'. Therefore, the weapon system design 
selected may not necessarily provide the U .S Navy with the 
"best” computer architecture available, but the overall 
system approach is probably the soundest and the most cost 
effective for the Navy. 

In general, selection problems may be classified into 
the following categories (12). 
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Processing mode selection 
Vendor selection 



a . 

b. 

c. Installation Selection 

d. System Component Selection 

e. Application Program Selection 

A definition of each category is not provided since the 
content is clear. 

2 . Performance Projection 

This evaluation technique may he the least frequently 
used. The problem here is to estimate the performance of a 
system not yet in existence (in some state of design). Thus, 
the evaluation is oriented toward a new system design, both 
hardware and software. The evaluation technique pursued in 
this research is encompassed within this category. The 
performance evaluation of algorithms run on a particular 
computer architecture is mostly concerned with performance 
prediction and is restricted, in general, to some form of 
computer modeling or simulation. In section V a method of 
conceptually representing computer systems by use of a 
concurrent control system model is explained. This method 
forms the basis for the performance prediction system 
developed by Cox (4) and modified for use here. 
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3 . Performance Monitoring 



Cnee a system is operational, monitoring provides 
data on the actual performance of the system. The 
performance statistics that may "be obtained while executing 
test programs aid in future equipment procurement decisions 
and are employed by the system user for system tuning) in 
forecasting the impact of changes in the system (either in 
reconfiguring the hardware or in improving executed software 
modules). The imoact of future technology and computer 
architecture will greatly affect performance monitoring at 
all levels of the computer system. Internal and external 
instrumentation will provide data accessible to the 
performance evaluator. A distinction should be understood 
here between performance monitoring (continuous) and an 
evaluation study. Continuous monitoring is usually performed 
for a substantial portion of the lifetime of the existing, 
running system. Its objective is to keep the system's 
performance under observation in order to detect performance 
problems as soon as they arise. An evaluation study is 
generally much more limited in time and is usually triggered 
by the identification of a performance problem or the 
suspicion of its presence. The following sections delineate 
the evaluation aspects at various hardware levels. 
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a. At the Chip Level 



With the trend to large scale circuit integration, 
performance evaluation through hardware instrumentation is 
becoming less flexible. The number of leads remain constant 
or decrease while the number of functions increase with the 
consequence of fewer test points per function being 
available. Since the cost per gate has reduced by a factor 
of 100 over the last ten years, it is now economically 
feasible to devote some of the circuitry in these chips to 
auxiliary functions such as performance monitoring. This 
will provide built-in data analysis without the addition of 
any hardware . 

b. At the CP-I/0 Level 

At this level the large - scale integrated circuit 
chips will be interconnected in various ways to implement 
the hardware instrumentation. Chips such as microprocessors 
will be used to do the actual work in this area. As with the 
previous level, lack of test points is a major problem; 
microprogramming causes an elimination of some probe points. 
Also, more test points are lost due to the trend towards 
eliminating peripheral channels. Costs can be reduced by 
integrating device control units into the processor and 
transferring information as serial bit streams. 
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c. At the Systen Level 



At this level, huilt-ln hardware monitors may 
provide additional assistance. The performance statistics 
collected by the associated hardware/software can be time 
correlated through the use of other microprocessors. The 
result is two fold: first to reduce the overhead of whatever 
software instrumentation is still required, an'! second to 
eliminate the need for external monitoring devices. The 
important advance at this level is that performance data 
will be stored under the system's database management system 
which will allow for on-line display of performance 
monitoring data. The data is therefore available for on-line 
input to various scheduling algorithms used to "fine tune” 
the system dynamically. A major draw-back to this method may 
be that the evaluation schemes will have difficulty in 
dealing with the virtual environment of present and future 
systems. An additional way would be the tendency to less 
secure systems because of the required critical parameters 
associated with the performance evaluation schemes. 

d. At the Network Level 

Distributed processing is the functional 
distribution and cooperative processing of user applications 
among multiple, separately located computer systems of the 
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same and/or different size and characteristics. The 
decreasing cost of hardware coupled with the increasing 
performance of distributed systems offers some advantages to 
performance evaluation at this level. Performance data can 
he collected locally at each site and transmitted to a 
central cite for evaluation and will provide a baseline for 
network tuning. Prom a global viewpoint though, more factors 
must be taken into account to assure that suboptimization 
does not occur. 

C. SUMMARY 



This chapter has pr 


ovided a 


partial 


outline of 


performance evaluation 


techniques 


used 


for computer 


evaluation. Other specific 


techniq ues 


such 


as benchmark. 


kernel, analytical model 


, synthetic 


programs, etc. are 


available but not discusse 


d here. A th 


orough 


discussion is 


provided in reference 


4. These 


areas 


are selection 


evaluation, performance 


prediction 


and 


performance 



monitoring. The DOT) requires a more defined approach to all 
these areas but is most lacking in performance prediction 
techniques . 

The next section describes a predictive method which 
will be applied in this thesis. 
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IV. SEAFIP.E (ELSCTP.O-OPTICAL FIRE CONTROL SUBSYSTEM) 



A. INTRODUCTION 

This section provides an overall description of the 
SEAFIRE Program and outlines its intended capabilities. 
SEAFIRE is presently in the Engineering Development (ED) 
phase of the weapon system development process with system 
deployment expected sometime during the mid 19S0's. A 
Request for Proposal was released to industry and was 
responded to hy a number of contractor teams. A thorough 
evaluation of these proposals, which included technical, 
management, cost and schedule factors, was performed over a 
ten month period resulting in contract award to industry 
during 1979. The computer subsystem section of the KFP is 
more formally described and the computer architecture 
response to this section is described at the component 
level . 

B. SEAFIRE DESCEIPTION 

1 . Subsystem Definition 

SEAFIRE is an electro-optical fire control subsystem 
modular addition to shipboard gun fire control systems 
(GFCS). This addition will allow control of the guns and 
gunfire by the GFCS when ship's sensors can designate 
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certain targets to SEAFIRE for which an electro-optical 
sensor is effective. SEAFIRE will also allow uninterrupted 
operation of GFCSs when the GFCS sensors are ineffective 
because of performance degradatior or are incapacitated by 
eouipment failure, casualty or tactical limitations. SEAFIRE 
shall consist of an optical director (above deck) and 
control, test and display units. As a subsystem integrated 
with a GFCS, SEAFIRE will perform the following functions 
against Surface Major Combatants, shore 
vehicles/installations, surface coastal defense craft and 
river patrol craft(22): 

a. Target Detection-SEJ^FIRE will provide the 
GFCS with day and night, passive electro-optical imaging for 
detection, manual and automatic angle tracking, and active 
laser rangefinding. SEAFIRE will be capable of performing 
these operations against sea, surface and shore-based 
targets- which can be engaged by the GFCS during electronic 
countermeasures (ECM) , electro-optical countermeasures 
(EOCM) and Emission Control (EMCCN) conditions. 

b. Target illumination - Once SEAFIRE has 
established track of a target, SEAFIRE will be capable of 
providing laser target illumination for laser-guided 
ordinance . 

c. Other fire control functions - SEAFIRE will 
be capable of tracking reference points (landmarks, buoys, 
etc.) to provide navigation data to the GFCS for indirect or 
offset firing. SEAFIRE shall be capable of sharing its line 
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of sight (LOS) to the LOS of the GFCS radars for target 
identification and check sighting. 

d. Ancillary Functions - When not employed as a 
target tracking sensor for fire control, the inherent 
capabilities of SFAFIRE will provide ancillary functions 
including, hut not limited to: detection of chemical agent 
clouds, and aiding in navigation, station keeping, friendly 
operations, surveillance, intelligence collection, swimmer 
detection and underway replenishment. 

In addition, SEAFIRE will he capable of being configured 
as a SEAFIRE independent GFCS for applications aboard ships 
on which no other GFCS exists. As a SEAFIRE independent 
GFCS, SEAFIRE should be capable' of performing, in addition 
to a, b, c, and d above, all functions necessary to engage 
and direct gunfire against all trackable targets. These 



functions 


will includ 


e, but 


not 


be limited to: 


direct 


acceptance 


of tactical 


informa 


ti on. 


interface 


with 


ship's 


stable reference, gen 


eration 


of 


gun orders 


and in 


ter face 



with gun mounts. 
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2 . SEAFIRE General Description 



SEAFIRE will be comprised of a director, passive 
imaging sensors, laser transmitter and receiver, as well as 
support, display, and control devices. SEAFIRE controls and 
display will be integrated into the consoles in the MARK 36 
and 92 GFCS applications. The controls and display in the 
MARK 63 GFCS application will be configured as a drawer of 
the AN/SPG-53 radar console. SEAFIRE will have an 
independent console in the SEAFIRE independent GFCS. The 
following major component list represents the SEAFIRE 
baseline(21) : 

t 

Director 

Laser Rangefinder/Illuminator (LR/I) 

Thermal Imaging Sensor (TIS) 

Television Sensor (TVS) 

Computer, Computer Program, and Related Equipment 

Maintenance Panel 

Interconnecting Cables 

Remote Video Displays 

Support and Test Equipment 

Console 

Automtic Video Tracker (AVT) 

Interface Module 

Video Character Generator 

Video Processor 
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Real Time Clock 



SEAFIRE is depicted in the functional block diagram of 
Figure 1 . 

3 . SEAFIRE Operational and Organizational Concepts 

SEAFIRE will be used in conjunction with the MARK 
86, 68 (digital), 92 and SEAFIRE independent GFCSs with 
ship's interface being provided through the GFCS, except in 
the SEAFIRE independent GFCS. In all applications , SEAFIRE 
mode structure and controls should be designed to minimize 
operator work load. The following list represents some 
SEAFIRE operational concepts. 

a. For engagements in which the fire control 
radars can provide adeauate track data, SEAFIRE may be used 
predominantly in DESIGNATION/SLAVE for check-sighting, 
threat evaluation, spotting corrections for fall of shot, 
and kill/damage assessment. 

b. For engagements in which the fire control 
radars have degraded performance due to ECM or clutter, 
SEAFIRE will provide independent target tracking data. The 
fire control operator can then select the sensor which is 
providing the best track data. 

c. In the event of a detection/track function or 
equipment failure of the GFCS sensor(s), SEAFIRE will 
provide a total casualty capability for the GFCS, 
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SEAFIRE FUNCTIONAL BLOCK DIAGRAM 
Figure 1 
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allowing continued gun and gunfire control by providing 
target tracking data. This will be accomplished by using the 
GFCS displays and controls, where practical, and the GFCS 
computer to perform the gun control functions such as 
ballistics, ammo select, fuze function and code set, signal 
data transmission and mount status. 

d. Under EMCON, the SSAFIRE passive imaging 
sensors may be used in horizon search, or to evaluate 
contacts detected by the ship's other passive sensors. If 
tactics permit limited emissions, the passive imaging 
sensors may be used with the Laser Rangef inder/Illuminator 
(LR/I) transmitting single shot to generate fire control 
solutions while remaining covert. 

e. For Laser Guided Ordnance (LGO) engagements 
SEAFIRE will, as a minimum, provide laser target 
illumination during the actual guidance time of the LGO. To 
minimize operator workload during this critical period of an 
engagement, SEAFIRE should be optimized for automatic target 
tracki ng . 

C. REQUEST FOR PROPOSAL 

As previously mentioned, a Request for Proposal (RFP) 
was released to industry for design and support of SEAFIRE. 
The contractor's response required not only a firm system 
design but also data substantiating his awareness of and 
implementation experience in production and life cycle 



support of major weapons systems. The following is a list of 
volumes included in the’ cortractor's proposal: 

1. Prime Item Development Specification 

2. Interface Definitions 

3. Master Test Plan 

4. Substantiating Technical Data 

5. System Project Management 

6. Training 

7. Support and Test Equipment Plan 

8. Contractor Furnished Spares and Repair Parts 

9. Producibility Engineering and Planning 

10. Technical Manual Organizational Plan 

11. LAMPS Electro-Optical POD Engineering Considerations 

12. Cost Data 

The above list depicts the depth of design/suppor t 
detail required of the contractor and are only mentioned to 
provide a top level view of the information used by the U.S. 
Navy evaluation team. 

1 . -Micro processors /Firmware Requirements 

The SEAFIRE computer (see Figure 1) is an integral 
subsystem which provides for processing of all data 
necessary for the functioning of the system. The word 
computer is a. misleading term because it connotates a single 
item. Although the SEAFIRE contractor was provided an 
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AM/UYK-20 computer set with peripheral equipment for use 
during system development and check-out, in actuality he was 
not prohibited from using additional imbedded processors to 
support/enhance the AN/UYK-20 processing capabilities. 
Specifically the use of microprocessors was encouraged. 

The P.FP stated that microprocessors introduced in 
SEAFIRE would be selected based on performance, 
logistic/maintenance support, ease of programming and cost. 
Additionally, microprocessor architecture would have to be 
designed to emulate a subset of the AN/UYK-20 computer 
instruction repertoire such that presently available Navy 
development software (e.g. CMS-2 compiler, assemble debug 
tools, data retrieval, data reduction, etc.) could be used 
to minimize development/life cycle support risk and cost. At 
least a 20 percent memory reserve and a 35 perqent 
processing time reserve applies to each processor. In 
addition, the firmware development/documentation/testing and 
review would be treated the same as the software development 
documentation/testing phases. Firmware is defined as all 
software that is not resident in the AN/UYK-20 and is 
necessary for the operation of SEAFIHE. This includes all 
programs developed for microprocessors, microcomputers, and 
microcontrollers. The microprocessors were also to be 
designed such that effort required to change the program for 
an inservice SEAFIRE would be minimized. 

Based on the above description in the RFP, each 
contractor team responded with a distincly different 
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computer architecture for SEAFIRE. Due to this fact and 
others as stated before, the evaluation of varying computer 
architectures on the same strict performance factors 
presented a difficult problem and did not necessarily result 
in the "best" computer architecture selection. Be that as it 
may, the design presented in the next section is the 
evaluation ob.lect for this thesis and it is hoped that as a 
result of the performance evaluation, specific proposals can 
be suggested which may provide possible system enhancements. 

D. PROPOSED CONTRACTOR SYSTEM DESIGN 

1 . System description 

SEAFIRE, as described by the system contractor 
(21), is an Electro - Optical Fire Control Subsystem (EOFCS) 
modular addition to existing shipboard Gun Fire Control 
Systems (GFCS) Mk 86, Mk 68, and Mk 92. This addition allows 
those functions previously defined. 

The modular design of SEAFIRE permits it to be 
configured as an independent GFCS for application onboard 
ships on which there is no other GFCS. ( See Figure 2) As an 
independent GFCS, SEAFIRE can perform the functions listed 
above and all functions neccessary to engage and direct 
gunfire against all trackable surface targets, including 
direct acceptance of tactical information, interface with 
own ship sensors, generation of sun laying orders, and 
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SEAFIRE INTEGRATION BLOCK DIAGRAM 




i I 




interface with gun mounts. 



2 . General Description 

SEAFIRE comprises two primary equipment groups, 
which are implemented in accordance with the Standard 
Electronic Module (SEM) program: 

a) The above deck equipment, consisting of the EO 
director. The EO director includes an enclosed turret, which 
is mounted on the outer gimbals of the SEAFIRE pedestal. The 
turret enclosure is designed to house the Television Sensor 
(TVS), Thermal Imaging Sensor (TIS) and Laser Rangefinder/ 
Illuminator (LR/I). The turret is temperature-controlled to 
optimize sensor performance. 

b) The below deck equipment, consisting of the Below 
Deck Processor (BDP), Pedestal Electronic Cabinet (PEC), 
Environmental Control System (ECS), Power Converter Unit 
(PCU), three remote video displays, and a console. 

A common SEAFIRE interface allows integration with 
host or independent GFCS without hardware or software 
modifications. The console for the independent GFCS includes 
the processing for gun order generation and interface with 
own ship systems. This impacts only the external interface 
to the applicable ship and not the basic SEAFIRE interface 
de sign . 

System processing is performed in the AN/UYK-20 
computer programmed in the CMS-2 language . Computer program 
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components are required to implement the following 
functions: Executive, Input/Output, Control, Displays, 
Director Control, Target Motion Analysis, Fault 
Isolation/Detection, and Data Extraction. The program is 
constructed in modules, with each module structured to 
perform one of the processing functions. The multitude of 
functions that must he performed within the system are 
interfaced and monitored for correctness hy the BDP 
Interface Controller, which also performs the core 
activities associated with fault detection and location. 

As previously mentioned, the contractors' use of 
microprocessors was encouraged by the U.S. Navy. The 
contractor has chosen to implement microprocessor technology 
in the BDP unit. Specifically, microprocessors or 
microcontrollers are implemented in the following units of 
the BDP: 

a) Interface Controller (IFC) 

b) Automatic Video Tracker (AVT) 

c) Data Director (DD) 

It was originally intended to perform the analysis 
in this thesis on algorithms running on the microprocessor 
architecture. But since much of the architectures' software 
and hardware is still in the process of design and the fact 
that several areas may currently be proprietary to a 
contractor or subcontractor, these architectures were not 
evaluated. The particular facet of the system evaluated 
(AN/UYK-20 Computer Program Components) will be explained in 
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a later section. 



3 . AN/UYK-20 Functional Description 

This section provides an overview of the software 
functional Computer Program Configuration Item (CPCI) and 
its included Computer Program Components (CPCs). The 
software architecture and interface are also described. The 
SEAFIRE computer serves as the controlling center of the 
SEAFIRE system, receiving data from its separate components, 
and routing information to those components reouiring data 
from other sources (see figure 3 ). 

The SEAFIRE Interface will provide the SEAFIRE 
Computer with the means to communicate with all of the 
SEAFIRE hardware components, collecting data from each 
component and transferring these data to the SEAFIRE 
Computer in a single block. Similarly, the SEAFIRE Interface 
will receive outputs from the SEAFIRE Computer and 
distribute these data among the SEAFIRE hardware components. 
To the SEAFIRE Computer, all of the SEAFIRE hardware 
components appear to be a single device, because a single 
block transfer is performed for both input and output. 
Furthermore, a single input interrupt and single output 
interrupt is involved. Eue to the appearance of a single 
input/output device relative to the SEAFIFE Computer, the 
software is discussed in terms of the SEAFIRE Interface (le, 
same as Interface Controller or Below Deck Processor). 
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SE AFIRE HARDWARE COMPONENT BLOCK DIAGRAM 

Figure 3 
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The host GTCS Operator will he able to control and 
nonitor the SEAFIEE System at the Weapon Control Console 
(WCC). The WCC is upgraded to include a SSAFIRE Control 
Panel for control, and a shared Video Display for 
monitoring. The Television Sensor (TVS) or Thermal Imaging 
Sensor (TIS), used with the AVT, and director position 
readouts will provide the SEAEIRE Computer information 
neccessary to determine target azimuth and elevation. The 
Laser Rangefinder/I lluminato r (LR/I) will provide the range 
to the target. Using information from these sources, the 
SEAFIRE Computer will he capable of outputting target 
position, velocity, and acceleration to the CFCS for 
engaging the target. The optically aligned TVS, TIS, and 
LR/I common optical pointing will he controlled by a single 
azimuth and elevation rate command from the SEAFIRE Computer 
(see figure 4) . 

The target image data received by the TVS and TIS 
will be sent to the AVT, where the target position is 
calculated. The AVT will determine target position relative 
to the upper left corner of the video raster and send the 
target relative position data to the SEAFIRE Computer at a 
6? Ez rate. 

AVT data may come from either the TVS or TIS, but 
not simultaneously. The data source is specified by the 
operator at the SEAFIRE Control Panel. Additional options 
are available at the SEAFIRE Control Panel that affect the 
data flow from the TVS/TIS to the AVT and actual processing 
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SEAFIRE HARDWARE COMPONENT DATA FLOW DIAGRAM 

Figure 4 
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within the AVT, embedded microprocessor. The operator may 
select one of up to six filters to modify the video input at 
the TVS/TIS. For the TIS only, he may control the Gain, 
Bias, and select either Black or White track. For the 
TVS/TIS he may control video Enhancement, Focus, and select 
either Wide Field Cf View (WFOV) or Narrow Field Of View 
(NFOV). At the AVT, he may select either Scene or Point 
digital tracking. 

The SEAFIRE Computer will pass the target position 
through a Kalman Filter? (1) to smooth the target position 
to a steady state, (2) to calculate target position, 
velocity, and acceleration and (3) to predict where the 
target will be in the next update cycle. The SEAFIRE 
Computer will then output target position, velocity and 
acceleration via NTDS Slow Interface, to the GFCS, so that 
the GFCS can compute a ballistic solution. The data input 
and output over the NTDS Slow Interface will be identical 
for the four configurations cf the SEftFIRS System (Mk 86, Mk 
68, Mk 92 and Standalone)? therefore, only one version of 
the computer program need be maintained. The development and 
maintenance cf only one computer program reduces costs and 
accents software commonality. The SEAFIRE Computer also will 
output commands to move the Director so that the target will 
remain in the TVS/TIS FOV . 

The SEAFIRE Computer contains one Computer Program 
Configuration Item (CPCI)? the Operational CPCI. The 
Operational CPCI is used as a GFCS to provide target 
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tracking and engagement and to maintain 
in a state of operational readiness, 
performs eight major functions: 



a ) 


Executive 




b) 


Input/Output 




c) 


Control 




d) 


Display 




e ) 


Tracking 




f ) 


Director 




g) 


Fault Isolation 


/Detection 


h) 


Data Extraction 




The CPCs listed 


below perform 



functions of the Operational CPCI: 
a) Executive 



the SEAEIRE system 
The Operational CPCI 



the eight major 



h) 

c ) 

d) 

e ) 

f ) 
s. ) 

h) 

i) 

j ) 

k) 

l ) 

m) 

n ) 



SEAFIRE Input Interrupt 
SEAFIPE Output Interrupt 
NTDS Slow Input Interrupt 
NTDS Slow Output Interrupt 
NTDS Fast Input Interrupt 
NTDS Fast Output Interrupt 
Control Panel Input 
Control Panel Processor 
Director 
Designation 

Target Motion Analysis 
Alphanumeric Display 
Symbology Display 
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o) Built In Test 

p) Performance Monitoring 

g) Data Extraction 

r) Clock Synchronization 

The functions allocated to each will not be described 
in detail. The data flow between each of the above CPC 
functions is shown in Figure 5. As can be seen Target Motion 
Analysis (TMA) it is a major central function to the system 
as it includes I/O to several other key functions. A 
description of the TMA is delineated in the next section. 

4. Target Motion Analysis (TMA) 

The TMA CPC is called by the Executive CPC at a 4 Hz 
rate to compute target position, speed, and acceleration for 
output to the ores and to the Display CPC. Executive rate 
will be 4 Hz since GECS outputs are required at this rate. 
The TMA CPC will use the AVT reported target position 
relative to the raster upper left corner position, Boresight 
Offset, Sensor Type, and Director Azimuth and Elevation to 
determine the target position, velocity, and acceleration. 

The Director will provide inputs neccessary to 
determine Sensor Line Of Sight (LOS) in terms of azimuth and 
elevation, and the ATT will provide inputs such that target 
azimuth and elevation relative to the LOS can be obtained. 
In manual track, only the Director angles are used. The LR/I 
will provide target range as the input. 



53 




SEAFIRE COMPUTER SOFTWARE DATA FLOW 
Figure 5 
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The AVT will report the 
elevation error. This position 
position relative to the LOS, and 
for the effects caused by Control 
the position in elements must 
degrees. Control Panel selections 
follows : 



target a 
must h 
must he 
Panel se 
he con 
have the 



zimuth e 
e transfo 
adjusted 
lections . 
verted to 
effects 



rror and 
rmed to a 
further 
Finally, 
units in 
listed as 



a) The number of degrees/element is different 
depending on wide or narrow FOV selection, 
h) The Foresight offset varies as a function of 
TVS or TIS sensor selection. 

c) The algorithm can he changed, and therefore, the 
target position. 

The TMA CPC will include the necessary processing 



to ; 

a) Correct for angle bias, convert target data 
to the appropriate reference frame, and correct 
for parallax. 

h) Prefilter the data to correct for timing delays. 

c) Perform TMA computations reouired to derive 
smooth target state variables (position, velocity, 
acceleration) in both the stabilized Spherical 
and Cartesian coordinate frames. 

d) Perform necessary computations during coast 
conditions . 

e) Output track quality data. 

At the end of the Kalman filter, maneuver detection 
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is performed. The maneuver detection subroutine is part of 
the TMA CPC but is not discussed due to its classification. 

E. SUMMARY 



Now that the system has been described and methodologies 
have been discussed in general for performance evaluation of 
computer systems, the next logical step is a specific 
application of one of these techniques. The next section 
provides a description of the performance tool that is to be 
applied in the evaluation of the SEAPIRE system. 



f 
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V . USS OF AN EXISTING COMPUTER SYSTEM PERFORMANCE TOOL 



A. INTRODUCTION 

The methodology to be used for the computer performance 
evaluation is the one designed by L. A. Cox, Jr. (4). This 
section provides a summary of his approach. 

In his dissertation, Cox described the develonment of a 
methodology for efficiently predicting concurrent computer 
system performance. This methodology allows the estimation 
of performance of an existing (or conceptual) computer 
organization operating on a linear mathematical algorithm. 
An existing program is taken and the control structure of 
all or some representative kernel of the code is expressed 
in a fashion which makes the potential parallelism 
exploitable. For a given computer system, the control 
structure dictated by the software can then be mapped onto 
the hardware structure, and the performance predicted. 

The key to this process is the representation of a 
kernel program or one of the basic cyclic events as a 
special kind of Petri Net simular to a marked, directed 
graph. In the directed graph, each arc can be regarded as 
having some propagation delay which is dependent upon the 
performance of the computer system executing the program. If 
these delays are fixed and known, then the question of 
performance reduces to a question about the minimum period 
for the cyclic behavior of the marked graph which represents 
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the program. 

A requester/server interface provides for construction 
of a two graph structure which allows the representation of 
algorithms and hardware organizations by separate graph 
structures. This permits each graph to be constructed in 
such a manner as to both express the control structure and 
to maintain a direct and meaningful representation of the 
important concepts being modeled, 

B. DEVELOPMENT OF THE DESIGN EVALUATION SYSTEM 



An effective concurrent computer system design tool must 
consider the characteristics of both systems and software on 
a more conceptual level. Hopefully, the same descriptive 
system could be empl oyed to describe both the hardware 
organization and the software requirements. The design 
evaluation system should provide for the inclusion of 
varying levels of detail in some hierarchical manner and 
should provide quantitative results of concurrent systems in 
some cost effective manner. 

Why use Petri-Nets for the predictive system? A 
Petri-Net may be thought of as an abstract, formal model of 
information flow. As such, it is possible to describe not 
only the information flow, but the controls and constraints 
of such flow. The Petri-Net graph models the static 
structure of a system in much the same manner as a flowchart 
models the structure of a computer program. In order to 
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represent the dynamic properties of the system to be 
modeled, a Petri-Net can he "eiecuted” to respond to the 
flow of information (or the occurrence of events) in the 
system. 

The static graph of a Petri-Net is composed of two types 
of nodes, circles which are traditionally called places, and 
bars which are called transitions. These nodes are connected 
by directed arcs which run from either places to transitions 

or from transitions to places. The source of a directed arc 

/ 

is referred to as the input, while the terminal node is 
referred to as the output. 

The dynamic execution of a Petri-Net is controlled by 
the position and movement of information, as represented by 
markers which are called tokens. Movement of the tokens 
proceeds according to certain rules. A token or tokens move 
when a transition fires. In order to fire, a transition must 
be enabled, that is all of the places which are inputs to 
the transition may fire. When a transition fires, the tokens 
are removed from the input places, and tokens are placed on 
all output places of the transition. 

Petri-Nets can model actual parallel processes by 
attaching some significance to token movement. For example, 
multiple outputs from a transition create multiple tokens 
upon firing, which could be interpreted as a "fork" 
operation activating multiple parallel processes. Similarly, 
the multiple inputs to a transition (which must all be 
marked for the transition to fire) could be interpreted as a 
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’join" operation terminating or merging independent parallel 
sequences . 

In each case, the status of the execution at a given 
time can he described by defining the status of the tol-cens. 
This distribution of tokens in a marked Petri-Net is called 
the marking, and defines the state of the net for a given 
instant. Figures 6 through 9 show the different stages of a 
marked Petri Net progressively at incremental time units in 
the system. 

As first formally defined by Petri, Petri-Nets were not 
always deterministic. For the purposes of performance 
evaluation, a small restriction was made to eliminate 
non-determinism, something not generally sought after in 
either hardware or software. 

Petri-Net concurrent control system models have many 
characteristics which are desirable in a concurrent computer 
system performance prediction system. This model is capable 
of representing both hardware and software systems and is 
hierarchical in nature. These characteristics are important 
in the predictive system. 

C. THE PETRI PERFORMANCE PREDICTIVE PACKA&E (P4) 

The reouirement for an architectural design aid existed. 
Cox created and implemented on an experimental basis, a 
performance prediction system based on Petri-Net models. The 
system, named P4 , standing for Petri Performance Predictive 
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Package, is described below. Major components of the P4 
system, and the system's intended employment are shown 
graphically in figure 10. The model implemented at NPS does 
not utilize the MAC macro expander or the macro library. 

The design of a new computer system (or the modification 
of an existing system) is usually initiated with the 
realization that a problem exists whose solution is both 
important, and not economically feasible in some sense. The 
P4 system is intended to be used in cases where a problem 
has been defined and a system architecture is to be 
developed. In response to this problem, the designer 
develops a solution concept. This concept includes the 
algorithmic portion of the problem, and some computer 
organization which hopefully will solve the problem within 
the various constraints. 

At this poirt the designer describes this solution 
concept in terms of the ?4 system. A P4 program (P5) 
consists of a discription of the computer system 
organization and capabilities. As we will see later, these 
descriptions are Petri-Mets, and in order to make use of the 
heirarchical nature of these nets, and to express system 
organizations in a more concise and convenient manner, a 
macroprocessor was included in the system; although one is 
not used in this thesis. A P4 program can be either a "pure” 
P5 description, or can make use of the macro facility, in 
which case it is referred to as a P5M description. This 
description of the solution concept is then 
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THE P4 SYSTEM OVERVIEW 



evaluated in a dynamic sense and produces an analysis of the 
system's predicted performance. 

The performance predictions are made on the basis of the 
execution of a Petri-Net simulator. This simulator operates 
on the P5 description of the proposed system. A complete P4 
program which is to he evaluated by the Petri-Net simulator 
consists of three sections: a hardware section, a software 
section and a dynamic section. The hardware section consists 
of a description of the basic subsystems of the computer 
system and some degree of subsystem interconnections. The 
network which represents hardware is ouantified in terms of 
its operation in time. The software section consists of a 
description of a Petri-Net which represents the algorithm to 
be executed on the system. This net is quantified in terms 
of the basic functions which are to be required of the 
hardware. The dynamic section contains certain output 
instructions and specifications of the Petri-Net's initial 
conditions. Formally, both the software section and the 
hardware section are merely descriptions of static Petri-Net 
structures. Performance prediction comes from the attachment 
of certain significance to the structures and certain 
restrictions on the movement of tokens or markers within 
these networks. 

The dynamic nature of Petri-nets is used to approximate 
the actitively of the proposed computer system as it 
executes the algorithm of interest. Accordingly, the two 
Petri-Nets, software and hardware, can be viewed in a 
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requester/server context. The software or algorithm makes a 
series of requests for the services of the computer system. 
The computer system fulfills these requests according to the 
constraints of its design. 

In the hardware net, events roughly represent operations 
in time. A collection of one or more events are used to 
represent a functional unit and its temporal response to the 
hardware control constraints. Token movement through the 
hardware net represents the data and control flow of the 
hardware system. A simple example of a ?5 hardware 
description is shown in figure 11. 

The software net's events represent "basic reouests for 
service. For example, an event might represent a request for 
an integer addition. The flow of tokens, which is initiated 
by a single marker on the event "BEGIN”, represents the 
logical flow of the algorithm. An example of the hardware 
and software net is shown in figure 12. 

Once these two Petri-Net structures have been defined. 



they can 


be 


executed 


together 


in a manner which 


will 


simulate 


the 


operation 


of the 


computer system. 


The 



interaction of the two nets is controlled by the 
‘requester/server token arbiter.’ The network simulation 
begins with the marking of the "BEGIN" node of the software 
net. This net is then executed according to standard Petri 
rules. The arrival of a token at a place in the net is 
interpreted as a request for service, the type of service 
depending on the type of the place. Upon arrival, the 
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P4 EXAMPLE (HARDWARE FUNCTIONAL UNIT) 
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A P4 EXAMPLE (SOFTWARE PROGRAM) 



arbiter is notified of the request for service. 

The arbiter removes the token from the net, and allows 
the software net execution to continue until such time as no 
further moves are possible. At this time, the arbiter 
initializes the appropriate, hardware units which correspond 
to the requests by marking them with tokens. 



The 


hardware net is 


then 


executed one 


step. If 


any 


tokens 


reach events 


which 


correspond to 


c ompletion 


of 


requested service, the 


arbiter 


is notified. 


Here again. 


the 



token is removed, and the token of the software net whose 
movement caused the original request for service is replaced 
by the arbiter. This cycle is repeated, with the execution 
of the software network, followed by execution of the 
hardware network. A P5 dynamic section and the P4 results of 
the examples shown in figures 11 and 12 are shown in figure 
13. 



Examples were tried by Cox and predicted results agreed 
well with actual measurements in most cases. Some cases with 
wide discrepancies pointed out a significant characteristic 
of the P4 methodology. When maximally parallel 
representations of the hardware and the software are 
provided to P4, the resulting prediction in most 
circumstances represents the "best case" execution time. 
This means that in cases where a system has been either 
implemented or simulated at the bit level, P4 predictions 
can be compared with bit level timings and used as an 
indication of the efficiency of the assembly code generated 
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BEGIN DYNAMIC NET; S5: EXECUTE 10; 

*PROGRAM EVENT J+K REQUESTS HW SVCS(l) 
MARK GATE WITH 1; *PROGRAM EVENT M+J REQUESTS HW SVCS(l) 

COMMENT: GATE ENABLED, TO ALLOW 

ONLY 1 OPERATION IN TIME = 1: 
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by either manual or automated means. 

The results Cox received indicated that the P4 
methodology provides not only a simple and accurate method 
for predicting computer system response but is economical of 
modeling resources as well. 

D. LIMITATIONS OF THIS APPROACH 

The Petri-Net is a concurrent control system model of 
demonstrated power? however, Cox indicated that it does have 
some limitations, perhaps the most significant of which is 
its inability to represent conditional events. Petri-Nets 
are not able to handle these conditions as they are 
traditionally designed. Some work has been done on 
developing extensions to Petri representations which 
consider this situation though a model which basically 
represents data as tokens is difficult to extend to data 
value dependent situations. 

Cox indicated that these extensive modifications do not 
appear to be Justified in view of the intended operation of 
the performance model. In general, the linear mathematical 
models which drove his research can be characterized by a 
single or at most a few main computational loops. The 
performance of the loop calculation drives the overall 
performance of the program. These loops can be represented 
as linear code, and their performance evaluated. Using this 
methodology, the conditional path problem is avoided. 
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Another limitation of the P4 approach stems not so much 
from the concept, hut from'the realization. Both software 
and hardware must he described in terms of descriptions of 
Petri-Nets. These descriptions are "programs" which are 
subject to all of the problems of any human generated 
program. 

Experience has shown that the representation of existing 
computer programs and algorithms as Petri-Nets is usually 
straightforward. Pew errors have occurred at this stage. The 
automatic generation of these descriptions from a FORTRAN or 
other algorithmic language source may be possible. 

The representation of hardware structures has proven a 
bit more complex. The hardware Petri-Net program must 
carefully include all explicit and implicit limitations to 
concurrency which the system will impose. This requires 
careful consideration of each design, and careful 
programming, sometimes by persons without significant 
programming experience. In hardware systems which make use 
of variable time intervals for execution (such as the data 
dependent nature of completion signaling devices), some 
average propagation delay must be substituted. This 
complicates somewhat the programming problem by demanding a 
detailed analysis of some sub-systems, and by including 
"average performance" figures. 

There is one other property which should be mentioned. 
Currently, there is considerable discussion of "data flow" 
computer architectures. These are machines which would be 



72 



based on the principle of executing instructions in response 
to the arrival of operands rather than in response to some 
sequential or explicit control flow. These machines are 
conceptually important because programs expressed in data 
flow form are free from sequencing constraints other than 
those required by the algorithm, and a processor using data 
flow representation can achieve highly parallel operation. 
In the Petri performance model, all pro,srams are expressed 
in essentially a data flow notation. A Petri performance 
prediction as previously described makes use of all the 
possible parallelism of both the hardware and software, and 
is thus "best case" in some sense. 

This "test case" prediction property stems from the fact 
that when properly represented in Petri-Net structures the 
hardware and software descriptions describe potential 
parallelism on a global basis. The mapping of requests for 
service into actual hardware operations makes use of this 
global parallelism, and the limits are only those explicit 
in either the hardware or software. It is this property of 
the Petri performance model that makes it useful in the 
evaluation of the efficiency of generated code, and makes it 
a valuable tool in investigations of compiler and language 
development for highly parallel machines. 

Cox's initial experience using the P4 methodology has 
shown that performance predictions based on dual Petri-Net 
representations of hardware and software structures are 
accurate and efficient in terms of resources required to 
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make the predictions. Additionally, 



the system is easy and 



sufficiently general so as to permit detailed investigations 
of alternative computer system organizations such as would 
he expected in the design and development of a new system 
such as SEAFIRE. 

E. SUMMARY 



The Petri performance model has 
must he understood before it c 
however, when intelligently used, i 
fulfilling all the goals of an i 
for use in the conceptual developme 
system organizations. The next sect 
implementation of the technique des 
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VI . I ^^PLBM7NTATI ON /EXPERIMENTAL PROCEDURES 



A. INTRODUCTION 

This section provides a description of the hardware and 
software model for SEAFIRE and how this model was executed 
by the Petri-Net simulator. Some of the detail that was 
required concerning the actual functioning of the SEAFIEE 
software was not available and therefore certain assumptions 
had to be made in order to develop these netsworks. The 
results of the analysis is covered as a function of the 
number of target loops (TMA) generated. 

B. A DESCRIPTION OF THE PROGRAM 

A discussion of Computer Software Data Flow at the CPC 
level was provided in Chapter IV along v;ith a diagram of how 
the CPCs interface (Figure 5). Since it was decided to 
perform the analysis at the CPC module level, a 
representation of the hardware function for each module is 
best represented as a time interval delay as predicted by 
the contractor. Table 1 depicts the contractor's timing 
estimates for each module in the Automatic Track Mode. These 
figures have been rounded off for ease of implementation. 

Figure 14 represents the SSAFIRE hardware (Machine Net). 
Each execution cycle (D1,D3, . . . .D263) is utilized for one or 
more of the CPCs of Table 1. The interrupt cycle represents 
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the first seven C?Cs listed. These interrupts occur at a 
rate of 645 per second; and since one cycle eauates to 100 
usee, one interrupt would occur approximately every 15.5 
cycles. The other calculations are linear representations of 
the execution time for each CPC. 

Figure 15 depicts the test estimate of how the software 
functions for SFATIEE in the Automatic Track Mode. Steady 
state was assumed so that the designation function could he 
ignored. TMA was first executed for a total of two target 
loops, then was varied on additional runs. The intention was 
to determine the loading capacity for the SEAFIEE computer 
at these varying stages of number of target loops. The other 
routines are interrupt driven from a clock and are depicted 
in the overhead loop. 

As previously mentioned, the basic simulator was 
available in a form which ran on a CDC-6700 computer. A 
large amount of effort to modify this simulator resulted in 
the program of APPENDIX A that now runs on a PDP-11/50 
minicomputer at NPS. Computer printouts of the resultant 
output is not provided as it was felt that it would not have 
been of significant benefit to the reader. The results of 
the analysis are discussed in the next section. 
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Computer Program 
Components 



Time Per 



Rate (Hz ) 



Executi on( 100us ) 



Executive 1 
SEAFIRE Input Interrupt 1 
SEAFIRE Output Interrupt 1 
NTDS Slow Input Interrupt 1 
MTDS Slow Output Interrupt 1 
NTDS Fast Input Interrupt 1 
NTDS Fast Output Interrupt 1 
Control Panel Input 4 
Control Panel Processor 6 
Director 6 
Designation 70 
Target Motion Analysis 260 
Alphanumeric Display 12 
Symbology Display 20 
Built-in Test 3 
Continuous Monitoring 120 
Data Extraction 3 
Clock Synchronizer 1 
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SEAFIRE COMPUTER TIMING ESTIMATE 
FOR AUTOMATIC TRACK MODE 



TABLE 1 




OUTLINE OF SEAFIRE HARDWARE 



REPRESENTATION 



Figure 14 
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SEAFIRE SOFTWARE (AUTOMATIC TRACK MODE) 



C. PRESENTATION OF RESULTS 



Initial results showed that the performance of the 
SEAFIRE system under development was approximately 30% telow 
design goals. Detailed analysis of the performance 
prediction showed significant problems in the methodology 
used to predict the performance. The multiple cyclic loon 
structures that are present in the SEAFIRE hardware/software 
representation present deadlock like competition for the 
hardware resources. Several times during processing it was 
evident that one cyclic loop would gain "control" of the 
hardware to the exclusion of all other processes; this loop 
consuming all hardware resources available. In a real time 
system, an Executive routine would drive the interrupts 
based on a clock. This reflects a problem of using the P4 
system as it currently stands to model real-time (interrupt 
driven) systems. 

Subseouent experiments indicated that the computer 
program flow could be manipulated in a cyclic (synchronous) 
manner to approximate an interrupt driven environment. 
Although the results closely replicate the contractor's 
predictions concerning the timing estimates required for 
program execution, a true representation of the real time 
fire control program was not created. 

It would also have been preferred if the processing of 
the embedded microprocessors could have been included; 
although it would have been rather simple to implement at 
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this level, the results would net have been significantly 
altered. A lower level of detail ( ie, software running on 
the actual hardware ) would provide the expected output of a 
faster, more efficient fire control solution which is less 
dependent on the centralized processor concept. 

The final timing estimates indicate that the proposed 
software design will meet the Navy's processing time 
requirements and have the capacity of expansion to include 
additional functions as system development proceeds. 

After further analysis, the structure of the programs 
were modified so that a maximum number of target loops could 
be accomplished without consideration for the administrative 
functions . 
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VII . CONCLUSIONS AND RECOMMENDATIONS 



The U.S.Navy and DOD are not doing an adequate job of 
specifying and developing the criteria to he used as 
standards f,or computer system evaluation and the prediction 
of their performance. The tools are available, but yet past 
methods are implemented without considering innovative 
industrial ideas. Only token amounts of funding are expended 
where the payoff is the greatest; in early conceptual 
development phases. 

Despite the advances in these areas, the question also 
arises as to whether the DOD can exploit these ideas with 
the support of industry. A number of approaches have been 
actively pursued over the last few years, however, there is 
not currently a firm direction in employing these new 
techniques in industry or DOD. 

A new dimension for the analysis of computer 
architectures has emerged. These methods can enhance the 
performance of computer systems and create an iterative 
atmoshere between industry and DOD which is required for 
future systems development. 

The methodology presented in this thesis should be 
considered as a partial effort in this direction. The 
approach is theoretically sound but its implementation 
requires a more thorough analysis with appropriate tailoring 
for its implementation. The rapid development of computer 
technology dictates that the DOD be able to better cope with 
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this pace. Further research and development into the causes 
and the nature of the problem of simulating an interrupt 
driven real-time combat system is highly recommended. 
Section V mentioned that the P4 system is directly analogous 
to data flow computing models. If the problem is inherent in 
the P4 system, it may very well be inherent in data flow 
computing models, which will inhibit their use in this type 
of analysis. For this reason, it makes further research in 
this area imperative prior to other implementations. It is 
recommended that this and other methodologies be explored 
further and hopefully utilized in the near future. 
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APPENDIX A 



PROGRAM LISTING 



petrinet.ftn Pace 1 Tue Nov ?7 06:18:55 1979 

1 C 
? C 

3 C PROGRAM PPIRI-NPT RFOUESTOR/SERVtR SIMULATOR 

<4 C 

5 C 

6 C 

7 C THIS PROGRAM IS THE REOUESTOR/SERVER INTERFACE 

8 c MODEL FOR I MPLE^EN I A T T ON IN THE P5 NETWORK. 

9 C 

10 C 

11 COMMON/NFT/ N£T(255,A),NTRNS(P55,3),NFRE(999,2), 

12 1MXTF,KTIVE,NFV,NTR 

13 COMMON/SOFT/ JNET(255,a),JTRMS(255,3),JEV,JTR 
lA C 

15 DO OOO'^ 1 = 1,255 

16 NET(I,l)rO 

17 NTRNS(T,1 )=0 

18 JNFT(I,n =0 

19 J[PNS(T,1)=0 

20 0005 CONIINIIE 

21 CALL IMIT 

22 C 

23 0010 continue 

2A CALL SCANRfS) 

25 IF CMATCHSI 1 ,SHBEGIN,5) .EO. 1 ) GO TO 0020 

26 IFfMATChSI 1 ,3HEND, 3) .EO. 1 ) GO TO OOAO 

27 CALL EPRRHR(1,7n MAIM, 0,0) 

28 GO TO 00 AO 

29 C 

30 0020 CONfTNUE 

31 IF (MA TCHS(2, 7HMACHINE, 7) .EO. 1 ) CALL STATICCNET, 

32 IM IRNS,NEV,MTP) 

33 IF(MArChS(2,7riDYMAMIC,7) .EO.l ) CALL DYNAMO 

39 IF (MATCmS(2, 7HPROGPAM, 7) .EQ. 1 ) CALL PGMNET 

35 IFfMAlCHSn ,3HFND,3) .EO. 1 ) GO TO 0010 

36 IF CMATCMSI 1 ,7HMACHINE,7) .NE. 1 .AND. MATCHSd, 

37 17HDYNAMIC,7) .NE. 1 

38 1 .AND. MATCriSl 1 ,7HPH0GRAM,7) .NE. 1 ) GO TO 0030 

39 GO TO 0010 

90 C 

91 0030 COMIINOE 

92 CALL ERRRRR(1,7H MAIN, 0,0) 

93 C 

99 0090 CONTINUE 

95 CALL 0UMP(NET,MTRNS,NFRE,NXTF,KTIME,MEV,MTR) 

96 CALL DUMP(JNET, JTRNS,NFRE,NXTF,KTIME, JEV,JTR) 

97 call TDU'''P 

98 CALL EXIT 

99 END 

50 C 

51 C 

52 SUBROUTINE INIT 

53 COMMON/nET/ MET(255,9) ,NTRNS(255,3) ,NFRE(999,2) , 

59 INXTF , KT IME ,('4E V , MTR 

55 COMMOiM/CTRLR/ T MODE , T CO ( 250 ) 

56 CGMMON/RAND/ RANOP 

57 C 

58 C START-UP DEFINE DEVICES FOR OUTPUT, 

59 C GET STARf-UP CTRLP MODE AND RANDOM MODE PROBABILITY 

60 C FROM TTY. CPEAIE A FICTICIOUS NODE 'RANDOM*. 
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Detrinet.ftn 



Pfiqe i! 



Tue Nov ?7 06:18:55 1979 



61 C 

62 C 

63 

65 

66 0100 

67 

68 0120 

69 

70 

71 

72 

73 

70 C 

75 

76 

77 

78 C 

79 C 

80 
81 
82 
83 
80 

85 

86 
87 

8« C 

89 C 

90 C 

91 C 

92 C 

93 C 
90 C 

95 C 

96 C 

97 C 

98 C 

99 C 

100 C 

101 C 

102 C 

103 C 
100 C 

105 C 

106 C 

107 C 

108 C 

109 C 
HOC 
111 C 
1 12 C 
1 13 C 

110 0200 
115 

1 16 
1 17 
1 18 
1 19 
120 



0PFN(UNIT=7,NAME= 'nETOUT .LSI ' ,TYPE='NEW ) 
0PEN(UN1T=5,MAME= 'DPOtMETINP. INP; 1 ’ ,TYP£='OLO’ , 
IPEADONLY) 

FORMAT f/,' NET-SIM VER. 20',//) 

WRITE 17,0100) 

FORMAT (5X, ’ aPROGRA''-'' START-UP MODE= ',15, 

1* RAND. PROd.= ’,F6.3,//) 

CALL SCANRf5) 

CALL X INTGR ( 1 , TMOOE ) 

CALL XFLOAT (?,RANDP) 

WRITE(7,0120) TMODE,RANOP 
CREATE THE PHONY NODE... AS NUMBER 255 
CALL NAMEH(NET(.?55, 1 ) ,6HRAN00M,6) 

RETURN 

END 



SUBROUTINE STATIC(KNET,KTRNS,KEV,KTR) 

CO'^MON/OMP/ NFREEI 

common /SC AN/ NUMB ,IWORD(15,10) 

COMMON/NET / NET (255,0) ,MTRNS(255, 3) , NFRE ( 999 , 2 ) , 
INXTF ,KTIME,NEV,NTR 
DIMENSION KNET(255,0) ,KTPNS(255,3) 

BYTE lEMP 

DIMENSION TEMP (10) 

NET DEFINITIONS 

NFI(N,1) = POINTER TO NAMES ARRAY yjHICH HOLDS NAME. 
NFT(N,2) = marker (0 — ) UNMARKED) 

NET(IM,3) = RESOURCE REQUIREMENTS (TYPE) 

NET(N,0) = OUTPUT FLAG FOR EXECUTION PRINT. 

NEV IS NUMPEP OF EVENTS 



NTRNS OEFINITIOf4S 
NTRNSfN,!) = NAME OF TRANSITION 

MTRM3fN,2) = POINTER TO TRANSITION INPUTS IN FREE 
SPACE 

NTRMS(N,3) = POINTER TO TRANSITION OUTPUTS 
NTR IS NUMBER OF TRANSITIONS 



M F R E E DEFINITIONS 
NFRE(N,1) POINTER TO AN EVENT IN NET 

NFRE(M,2) POINTER TO NEXT ENTRY IN NFRE UR NIL (0). 

NXTF IS POINTER TO NEXT FREE SPACE. 

BEGIN STAIIC LOOP TABLE BUILDING 
CONTINUE 
CALL SCAMR(5) 

IF (MATCHS( 1 , 3HEND, 3) .EO. 1 ) GO TO 0291 
IF (MA TCHS ( 1 , 7HDECLARF, 7) .NE . 1 ) GO TO 0290 
IF fMATCHS(S,5HEVENT,5) .EO. 1 ) GO TO 0210 
IF (MATCHS ( 5, 1 OHIPANST T ION, 10) .EQ. 1 ) GO TO 02ao 
GO TO 02PU 
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121 C 
12 ? 0210 
123 
129 

125 

126 
127 
123 
129 
1 30 
131 

13? 0?29 

1 33 

139 

135 0?30 

1 36 

137 C 

138 0290 
1 39 

190 

191 
1 92 
193 

199 0250 

195 
1 96 

197 

198 

199 
150 

151 0260 

15? 

153 

159 

155 

156 

157 0?70 

158 

159 

160 
161 
16 ? 

163 
1 69 
165 
1 66 

167 

168 

169 

170 

171 
17? 

173 
1 79 
175 
1 76 
177 
1 78 
1 79 
1 80 



0280 



0290 



0291 



0292 



CONTINUE 

CALL Jl'iORDC?, TEMP) 

NEX T = IFINDM(TEMP, KNET) 

IF f NEXT .ME .0) GO TO 0220 
KEV = KEV 1 

TFIKF\/.GT.255) GO TO 0230 
CALL NAMTNP(KNE r fKF\/, 1) ,2) 

CALL XINTGP(MUN'B,NEXT) 

KNE r CKFV , 3)=NEX f 
GO in 0200 
CONTINUt 

CALL EPRRRR(3,8h static, 0,0) 

GO TO 0200 
CONTINUE 

CALL EPRPRR(?,8H STATIC, 0,0) 

CONTINUE 

call JW0RD(2, TEMP) 

N1=IFIMDT(TEVP,KTRNS,KTR) 

IF CN 1 .EQ.KTR) GO TO 0250 
CALL ERRRRR(3,8H STATIC, 0,0) 

GO TO 0200 
CONTINUE 
CALL SCAMRT5) 

IF (MATCHS ( 1 , 3HEND, 3) .EO. 1 ) GO TO 0200 
IFCMATCHSC 1 ,5hINPUT,5) .EO. 1 ) GO TO 0260 
IF (MATCHST 1 ,6H0UTPUT,6) .EQ. I ) GO TO 0280 
CALL ERRPRP(5,8H STATIC, 0,0) 

GO TO 0250 
CONTINUE 

CALL JWOROfNUMB, TE'^'P) 

N2=IFIN0M(TENP,KMET) 

TF(N2.NE.O) GO TO 0270 

CALL EPRPRP(9,8h STATIC, IWORDTNUMB, 1 ), 0) 

GO TO 0250 
CON TTNUE 

CALL SETFRE(KTPNS(M1 ,2) ,M2) 

GO TO 0250 
CONTINUE 

CALL JWOPD(NU^•1B,TE^'P) 

M2=IFIN0N(TEVP,KNET) 

IF(N2.EQ.O) GO TO 0260 
CALL SETFRE(K TRNSTNl , 3) ,N2) 

GO TO 0250 

CONTINUE 

CALL £RRPRR(5,8H STATIC, 0,0) 

GO TO 0200 

CONTINUE 

IF (IMFPST .NE.O) GO TO 02«52 

IMFRST=1 

MFPEE1=NXTF 

CON TTNUE 

CALL LI3TX (KN£T,KTPMS,KFPE,NXTF,KTIME,KEV,KTR) 

RETURN 

END 
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0500 



181 

182 

183 

1 8a 
185 
) 86 

187 0295 

188 D9000 

189 D 

190 

191 

192 C 

193 C 
19a 
195 
1 96 

197 

198 

199 

200 
201 
202 
203 
2oa 

205 

206 

207 

208 

209 

210 
211 
212 
213 
2ia 

215 

216 

217 

218 

219 

220 
221 
222 
223 
22a 

225 

226 

227 

228 
229 



subroutine J1/'jOPD( number, STRING) 

BYTE IWORD 

COMMON /SC AM/ NUMB, Ivi-ORO( 15, 10) 

BYTE STRING 
DIMENSION STRINGMO) 

DU 0295 1=1,10 

STPIMGd ) = TnORD(MUMBFR, I) 

FORMAK • JWGRD:NUMBER, STRING: ' ,ia,2X, lOAl ) 
WRITF(7,O000) number, ( S TR I NG ( I ) , I = 1 , 1 0 ) 

RETURN 

END 

SUBROUTINE SFTFRF ( TPOINT, I VALUE) 

CUMMON/NFT/ NE T ( 255 , a ) , N TRNS ( 255 , 3 ) , MERE ( 999 , 2 ) , 
1NXTF,KT1 ME,nEV,NTR 

FOR TRANSTIION INPUTS OR OUTPUTS, SET UP AND 
ENTER VALUE IN ThE CHaiN POINTED TO BY IPOINT. 



SETFRE,0,0) 



0510 



230 D9000 

231 0 

232 

233 

23a 

235 

236 
237 
258 
23P 
2ao 



oaoo 



IF(IPOINT.FQ.O) GO TO 0510 
NEXT = 1P0INT 

CONTINUE 
NEXOLD = NEx T 
NEXT=NFRE(MEXT,2) 

IF(NExT.NE.O) GO TO 0500 
END OF CHAIN 
NxTF = NX TF+ 1 

IF (NX! F .GT .909) CALL ERRRRR(2,8H 

NFOE(NEX0LD,2)=NXTF 

MFRETNXTF, 1 )=IVALUE 

RETURN 

CONTINUE 

NXTF = NX TF 1 1 

IPOINT = NX IF 

NFRE (NX IF, 1 J = I VALUE 

RETURN 

END 



FUNCTION IFINDT(NAME,NTPNS,NTR) 

BYTE NAMF,Tfc'vP 

DIMENSION NAME( 10) , TEMP( 1 0) 

DIMENSION NrRNS(255,3) 

FIND THE TRANSITION 'NAME' IN THE TABLE i 
RETURN number 

FORMATC' IFl^iDT: N AME , NTP ' , 2X , 1 0 A 1 , 2X , I a ) 

WR I TE (7,9000) (NAME ( T ) , 1=1 , 1 0 ) ,NTR 
DO oaoo 1=] ,255 
IFTNDI =I 

TF(NTRNS(I, 1) .NE.O) CALL GE T N AM ( NT RNS ( 1 , 1 ) , TEMP ) 
IF (MA I CHC (MAW£, TEMP, 1 0) .EQ. 1 ) RETURN 
CON T TNUE 

DIDN'T FIND IT, SO CREATE IT. 

NTP=M rp + 1 

CALL NAMEIT (NTRNS(NTR, 1 ) ,NAME, 1 0) 
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201 




292 




293 




299 




295 




296 


C 


297 


C 


298 




299 




250 




251 




252 


c 


253 


c 


259 


c 


255 


c 


256 


09000 


257 


D 


258 




259 




260 




261 




262 


0500 


263 




269 


0510 


265 




266 




267 




268 


c 


269 


c 


270 




271 




272 




273 




279 


D9000 


275 


D 


276 




277 




278 


0550 


279 




280 




281 




282 


C 


283 


C 


289 




285 




286 




287 




288 


C 


289 


C 


290 


C 


291 


C 


292 


c 


293 


0600 


299 




295 




296 




297 




298 




299 




300 


C 



TFIN0T=NTR 

IF fNTR,LF.255) RF_TURM 

CALL tPRRRP{?,8H IFTNOT,0,0) 

RETURN 

END 



FUNCTION IF! NON (NA*^E r NET ) 

BYTE NAME, TERR 

OIVENSIOM MA*>'E ( 1 0) , TEMP ( 1 0) 

DIMENSION NET(?55,A) 

FIND the nave in the TABLE 
RETURN 0 IF NOT THERE 

FORMAT!' IFINON:NAmE ’,10A1) 

WRITE ( 7,90 00 ) ( NAME ( I ) , I = 1 , 1 0 ) 

IFINDN=0 
DO 0500 1=1 ,255 

IFfNEKl, n .NE.O) CALL GE I N AM ( NET { 1 , 1) , TEMP ) 

IF fMATCHC (NAVE, TEMP, 1 0) ,EQ. 1 ) GO TO 0510 

CON r INUE 

RETURN 

CONTINUE 

IFIN0N=1 

RETURN 

END 



FUNCTION MA IChC (S IRNGl , STRNG2 , KOUNT ) 

BYTE STRMOr, SIRNO? 

DIMENSION SIPNGl nO) ,STRNG?(10) 

MATCHC=0 

FORMAIf MATCHC: ’,2nOAl,2X)) 

WRITE (7, 900 0) (STRNGI (I), I = 1,10), ( S IRNG2 ( I) , I = 1 , 1 0 ) 
DO 0550 1=1, KOUNT 

IF(STRNG1(I).NF.STRNG2(I)) RETURN 

CONTINUE 

MATCHC= 1 

RETURN 

END 



SUBROUTINE LISTX (NET,MTRNS,NFRE,NXTF,KTIME,(MEV,NTR) 
BYTE TEMP 

dimension TEVP(IO) 

dimension net (255, 0) ,NTRNS(255, 3 ) , NFP£ ( 999 , 2 ) 

AFTER static HARDWARE NFT IS IN, DO AN ANALYSIS, 
FIRST PRIM! SYMBOL TABLE DUMPS, THEN DO STATIC 
CONFLICT analysts OF THE NETWORK 

FORMAT (//, 20 X , ' STATTC-STRUCTURE-ANALYSIS ' 

1 //) 

WRITE(7,0600) 

CALL DUMP(NET ,NTRNS,MFRE,NXTF,KTIME,NEV,NTR) 
WRTIE(7,0b00) 

PETUPN 

END 
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301 C 
30? C 

303 SUBROUTIME DUMP ( NE T , NTRNS , MF RE , NX T F , K T I ME , ME V , M TR ) 

309 RriE TEMP 

305 DI^’ENSION TEMPHO) 

306 OIMEMSIOM N£ T ( ?S5 , 9 ) , N TRNS ( ?55 , 5 ) , MF RE ( 999 , ? ) 

307 C 

308 0700 FORMAT (/,?Ox , ’NETWORK ARRAY DUMP TIME = ',15, 

309 1' EVENTS ',/,3X,' --|\|AME-- -MARKER- — TYPE', 

310 C ?'-- -OUTPUT- ’,//) 

311 0710 FORMAT f X, lOAl ,3110) 

31? WRTTF(7,07O0) KTIME 

313 DO 07?0 1=1, MEV 

319 CALL GFTMAM(NET ( T , 1 ) , TEMP) 

315 WRTTE(7,0710) ( T EMP ( T JK ) , IJK = 1 , 1 0 ) , ( NET ( I , J ) , J=? , 9 ) 

316 07?0 CUMTINUE 

317 0730 FORMA T (/,^OX, • TRANSITION TABLE AND FREE SPACE DU' 

318 1MR',/,3X,' --NAiMF-- INPUT PTR. OUTPUT PTR ',//) 

319 0790 FORMAT (X, lOAl ,?I 10) 

5?0 WRITF(7,0730) 

3?1 DO 0750 1=1, NTR 

3?? CALL GFTNAMCN IPNSC T , 1 ) , TEMP) 

3?3 0750 WRI TE(7,0790 ) C TEMP ( I JK ) , I JK = 1 , 1 0 ) , ( NTRNS ( I , J ) , 

3?9 1J=?,3) 

3?5 RETURN 

3?6 END 

3?7 C 
3?8 C 

3?P SUBROUTINE TDUMP 

330 COMMON/NET/ NET ( ?55 , 9 ) , N T RMS f ? 55 , 3 ) , NFRE ( 999 , ? ) , 

331 INXTF, KTIME, NEV, nth 

33? COMMON/SOFT/ JNE T ( 255 , 9 ) , J TRNS ( ?55 , 3 ) , JE V , J TR 

333 COMMON/DMP/ NFPEEl 

339 COMMON/NAMFl/NAMESf?03, 10) ,NXTNAM 

335 BYTE NAMES 

336 BYTE TEMPI, TEMP? 

337 DIMENSTON tempi ( 1 0) , temp? ( 1 0) 

338 0800 FORMA T fx , ’ ' ) 

339 0810 format f//,?0X, 'FREESPACE ',/,3X, 

390 I'-NU^BER- -event- --NEXT — ',//) 

391 0820 FORMA f f X , 1 I 10,?X, 1 OA 1 , 1 I 1 0) 

392 WRITE (7, 0610) 

393 DO 0830 I=t ,NXTF 

399 CALL GETNAM(NET (NFRE ( I , 1 ), 1 ), TEMPI ) 

395 CALL GFTMAM( JnET (NFREd , 1 ) , 1 ) , TEMP?) 

396 IF ( 1 .LE.NFREEl ) WR I TE ( 7 , 0820 ) I , ( TEMP 1 ( J ) , J= 1 , 1 0 ) , 

397 1MFRE(I,2) 

398 IFd.EQ. NFPEEl) WR T TE ( 7 , 080 0 ) 

399 IFCI .GT.NFREE 1 ) WR T TE ( 7 , 0820 ) I , ( T EMP2 ( J ) , J= 1 , 1 0 ) , 

350 1 NFREd, 2) 

351 0830 CONTTNUE 

35? 0>»90 FOPiviA T (5X ,' NAMES NXTNAM=',I9) 

353 0850 FORmahSX, 1 OAl ) 

359 WRITE(7,0890) MXTNAM 

355 DO 0860 T=1,NXTNAM-1 

356 0860 WRITE(7, 0850) ( N AMES d , J ) , J= 1 , 1 0 ) 

357 RETURN 

358 END 

359 C 

360 C 
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561 SUBROUTIME DYNAMO 

362 COMMON/NEf/ NET (255,^) ,NTRMS(255,3) ,MFRE(999,2) , 

563 1NXTF,KTI''>'E ,NEV,NTR 

36« COMMON/DYN/ loom (255) ,L00K2(255) 

365 CON’MON/SCAN/ numb, I'aORO(1 5, 10) 

366 C 

367 C INTERPREl DUNAM, K COMMANDS AND RUN SIMULATION 

56« C 

369 C 

570 IF (KTIME.EO.O) KTIME=1 

371 C 

372 0^00 CONTINUE 

373 CALL SCANR(5) 

37^ IF (MA TCHS( 1 , 3HF.Nn, 3) .EO. 1 ) RETURN 

375 IF (MATCHSC 1 ,^hMARR,a) .EG. 1 ) GO TO 0920 

376 IF f MA rCHS( 1 , 6hnuTPUT , 6) .EG. I ) GO TO 0930 

377 IF (MATChSC 1 , 7HEXECUTE, 7) .EG. 1 ) GO TO 09a0 

378 0910 CONTINUE 

CALL £RRRRR(5,flH OYNAMQ,0,0) 

300 GO TO 0900 

581 C 

382 0920 CALL MARKET 

383 GO TO 0900 

38^» 0930 CALL SEIOUT 

585 GO TO 0900 

586 0900 CALL EXEQ 

387 GO TO 0900 

588 END 

589 C 

390 C 

391 SUBROUTINE MARKET 

592 COMMON/NET/ NET(255,^) ,NTRNS(255,3) ,NFRE(999,2) , 

393 INXTF , KT IME , NEV , NTR 

390 common/scam/ numb, I/iORD( 15, 10) 

395 C 

396 BYTE TEMP 

397 DIMENSION TE»^P(10) 

398 C 

399 c mark an EVENT V'JiTH THE DESIRED VALUE 

000 C 

001 CALL JW0RD(2, TEMP) 

002 N1 = IFINDM(TEmP,imF n 

003 IF (N1 .ME.O) GO TO 1 000 

OOO CALL ERRRRP(0,8H MARKET , IWOPD (2 , 1 ) f 0 ) 

005 RETURN 

006 1000 CONTINUE 

007 CALL XINTGP(MU'^B, IVALUE) 

008 NET (N1 ,2) = IVALUE 

0(JQ RETURN 

010 END 

011 C 

012 C 

013 SUBROUTINE SEmuT 

010 CUMMON/NET/ NET(255,0) ,NTRNS(255,3) ,NFRE(999,2) , 

015 inxtf,ktime,nev,ntr 

016 BYTE IWGRD 

017 CGMMON/SCAN/ numb, I'aORD( 15, 10) 

018 BYTE TEMP 

0 1«5 DIMENSION TEvp(lO) 

020 C 



90 



pefrinet.ftn 



P aae B 



Tu*=> Mov 21 06: 18:55 1979 



C 

C 



C 

C 



CALL JWOPD (NUMB, TE^^P) 
Ml = lFIMDfJ(TE"^>'P,NFT) 
IFfiMI .ME.O) GO TO 1 100 
CALL EPRPRR(^i,8H 
PETUPN 

1100 COMUNUE 

MET (Ml ,a)=1 
RETURN 
END 



C 

c 

c 



SURROUTIME EXEQ 

CO^'i'-ION/NE T / NET(255,a),NTRMS(255,3),MFRE(999,2), 
1MXTF,KTIME,I'JE\/,MTR 

COMMON /SOFT/ J MET (255, a) ,JTRMS(255,3),JEV,JTR 
EXECUTE the REQIJESTOR/SERVEP NETWORK 



A21 
A22 
a23 
aaa 
a25 
A26 
a27 
A28 
A29 
^30 
a31 
A32 
A33 
a3« 

A35 
A36 
a37 
A38 
A39 
aao 

azj2 
AA3 
AAA 
A45 
AA6 

447 

448 

449 

450 
A51 
«52 
A53 

454 

455 

456 
A57 
458 

A59 1 IFIRE, KTIME) 

BYTE TFMP 



SET OUTPUT FLAG ON DESIGNATED EVENT 



SETOUT, I WORD (NUMB, 1 ) , 0) 



C 

C 



CALL XINTGR(2, I TIME) 

kltmit=ktime+itime 

1200 COMflNUE 

if(mim(£.ge.kltmtt) return 

CALL EXEQl (JMET, JTRNS,MFPE,NXTF, JEV, JTP, 1 , IGO, 

IK TIME) 

TFdGO.EQ.n GO TO 1200 
IF (KSUFT ( IGO) .eg. 0 ) RETURN 
CALL HUGO 

CALL EXEQl (NFT,NTRNS,NFRE,NXTF,NEV,NTR,0, IGO, 

IK TIME) 

GO TO 1200 
END 

SUBROUTINE EXEQl (KMET, I T RN , MERE , K TF , lEV, ITR, IFUNC, 



460 

A61 

4b2 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 
47 8 

479 

480 



DIMENSION TEMP(IO) 

COMMOu/DYN/ LOO^) (255) , LOOK 2 (255) 

DIMENSION KNET (255,4) ,I1RN(255, 3) ,NF RE (999,2) 
DIMENSTOM KPRINK255) 

EXECUTE THE SPECIFIED NETWORK FOR ONE CLICK 
IFUNC = 1 --) SOFTWARE NET, 

IFUNC = 0 — ) HARDWARE NET 

IFIRE = 0 --) NOTHING FIRED THIS TIME 
IFIRE = 1 --) ONE OR mqde TRANSITIONS FIRED. 



IFIRE=0 

1 300 FORMAT (X, 'TIMt=’ , 14, '\’ ) 
IFdFUMC.EQ. 1 ) GO TO 1310 
WRT1E(7, 1300) KTIME 
CALL HWRAND 

1310 COMITNUE 
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U81 




982 




983 




989 


1320 


985 


C 


986 




987 


C 


988 


c 


989 




990 




991 




992 




993 




999 




995 


c 


996 


1330 


997 


C 


990 


C 


99Q 




500 




501 


1 590 


502 




503 




509 




505 


C 


506 




507 


C 


508 




509 




510 


C 


511 


1 350 


512 


C 


513 




519 


1360 


515 




516 




517 




518 




519 




520 




521 




522 




523 


C 


529 


1370 


525 


C 


526 




527 




528 


1 380 


529 




530 




531 




532 




533 




539 


C 


535 


c 


556 


1 390 


537 


C 


538 




539 


1391 


590 





CALL MARKER (LOOK 1 ,KrjFT,ITRN,NFPE,KTF,IEV,ITR) 

DO 1320 r=l,TEV 

KPRIKT f I )=0 
CON r TNUE 

DO 1390 1 = 1, ITR 

CHECK aiHICH transitions ARE READY TO FIRE 1 
EXECUTE 

CALL marker (LOGK2,KrjFT, I TRM , NF RE , KTF , I E V , I TH ) 

IF (LOOKl ( I ) .EQ.O .AND. L00K2 ( I ) . EQ . 1 ) GO TO 1390 
IF TLOOK 1 ( I) +L00K2 ( n .EQ. 0) GO TO 1390 
IFfLOOKl f I) .EQ.L00K2(I) ) GO TO 1530 
CALL EPRPRR(6,7H EXEQ , T TRN ( I , 1) , 0 ) 

GO TO 1390 

COMTTNUE 

FIRING A transition - UMMARK INPUTS/ MARK OUTPUTS 
TFIRE=1 

NEXT=ITRN(I,2) 

CONTINUE 

IF (NEXT .EG. 0) GO TO 1350 

MEX0L0=NFXT 

MEX r = iMFRE (N£ X T , 2 ) 

CHECK IF MU TOKENS, .maybe USED ON THIS TRANSITION 
TF(KNET(NFRE(NEXOLn, 1) ,2) .EQ.O) GO TO 1370 
IF MO MORE TUKENS, HAVE TO BACK OUT OF TRANSITION 
KNE r (NFRF (NEXOLD, 1 ) , 2 ) =KMET (NFRE ( NEXOLD , 1 ) ,2)-l 
GO TO 1390 

CONI TNUE 

MEXT = ITRM( 1 ,3) 

continue 

TF(NEXT.EQ.O) GO TO 1390 

NEXOLD=NFXT 

NEXT=NFRF(NEXT,2) 

KNF r (NFRE (NEXOLD, 1 ) , 2 ) =KNET ( NF RE ( NEXOLD , 1 ) , 2 ) +• 1 
IF ( IFUMC.EQ. 1 ) CALL R S I N ( K ME T ( NF RE ( NE X OLD , 1 ) , 1 ) ) 
IF(IFUMC.EO.O) call PSOUT ( NF PE ( NE X OLD , 1 ) ) 

KPRIMT (NFRE (NEXOLD, 1 ) )=1 
GO TO 1360 

CUNT TNUE 

REPLACE SOME TOKENS.. THIS TRANSITION IS WIERD... 
TSTOPD=NEXOLn 
NEXr=ITRN(I,2) 

CONTINUE 

IF(NEXT.FQ.ISTOPD) go TO 1390 

NEXOLD=NEXT 

MEXT=NERE (T'EX I ,2) 

K'NE r(NFRE(NEX0LD,l),2)=KNET(NFRE(NEX0LD,l),2) + l 
GO TO 13P0 

END OE RAK-UP PROCESS 
COMT IMUt 
no 1392 J=1,IEV 

EORMA T (5X , ' * * * **E VENT ',10A1,' MARKED WITH ',1110, 
1 '***♦*' ) 
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sal CALL GFTNA^^(KNET ( J, n , TEMP) 

Sa? IFfKPRTiMT(J) .EH.l .AMD. K ME T ( J , a ) . NE . 0 ) 

Sa3 1 NRI TE(7, 1 391 ) fTEMP(K) ,K=1 , 10) ,KMET (J,2) 

Saa 139? CONTINUE 
sas C 

sab IFf IFUMC.EQ.O) KTIme=kTIM£+i 

sa7 RETUPN 

sa8 END 

sa9 c 

sso c 

551 SUBROUTINE hlAiGO 

552 COMMOim/NET/NET (?ss,a) ,NTPNS(?SS,3) ,NFRE(999,2) , 

553 pixtf,ktime,nfv,ntr 

ssa COMMON/CTRLR/ ImqOE, ICQ(?S0) , ICQPTR 

sss c 

556 C MARK AS many HARDWARE UNITS AS DESIRED 

557 C (ACCCORDING TO OUTSTANDING Srt REQUESTS) 

S5B C MOT TO EXCEED THE LTMIT OF ‘IMUDE*. 

SS9 C 

SbO C THEM SHIFT UP THE QUEUE, TCQ, AND RESET ICQPTR 

Sbl C 

Sb? C IF ICQPTR = 0 NOTHING TO DO, SO RETURN... 

Sb3 IF ( ICQPTP.EQ.O) RETURN 

Soa C 

SbS DO laoo T=1,TCQPTR 

Sbb NET ( ICO ( I ) ,?)=NET ( TCQ( I ),?) + ! 

Sb7 J=T 

Sb8 IFfI.-EO.IMODF) GO TO laiO 

Sb9 laun CONTINUE 

570 C 

571 laio CONTINUE 

S7? C REPACK QUEUE 

S73 DO ia?0 I=l,ICGPTR-J 

S7a .TCQ(T) = ICQf J + I) 

S7S laao CONTINUE 

S7b ICQPTRrlCQP f R-vI 

577 C 

578 RETURN 

579 END 

580 C 

581 C 

S8? SUBROUTINE HWRAND 

S83 COMMON/NFT/ NET(?SS,a) 

S8a COMMON/RAWO/ RANDP 

S8S C 

S8b C CHECK RANDOr/ EVENT AND MARK IT PROBABILISTICALLY. 

S87 C 

S8B PROB=RANf 1 1 , I?) 

589 IFCPROB.LT .RAljDP) Nt T ( ?SS , ? ) =NF T ( ?SS , 2 ) + 1 

590 RETURN 

591 END 

592 C 

593 C 

S9a SUBROUTINE M A RKER ( K R A Y , NE T , N TRNS , NFRE , MX TF , NE V , NT R ) 

S9S DIMENSION NET(?5S,a),MTRNS(2SS,3),NFREr999,2) 

S9b DIMENSION KRAYf2SS) 

S97 C 

S9B DO ISOO 1=1, NIR 

S99 KRAYfI)=n 

bOO ISOO CONTINUE 
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601 C 

60? 00 1530 1 = 1 , NTR 

603 K1=0 

60a K2=0 

605 C 

606 MEXT = iMTRNSn ,2) 

607 1510 CONTINUE 

608 TF(NFxT.FQ.O) go to 1520 

609 MEXOLD=NFXT 

610 ^'EXT = NFRF(MEXT,2) 

611 K2=K2+1 

61? IFINF. r(NFKE(NEXOLU,l),2).NE.O) Kl=Kl + l 

613 GO TO 1510 

6ia C 

615 1520 CONTINUE 

616 IFfKl.EQ.K2) KRAY(T)=1 

617 C 

618 1530 CONTINUE 

619 C 

620 RETURN 

621 END 

622 C 

623 C 

62 a SUBROUTINE PGMNET 

625 COM.MON/SOFT/ JNE T ( 255 , a ) , J TRNS f 255 , 3 ) , JE V , JTR 

6 2 6 C 

627 C THE SOFT.\ARF NET BUILD ROUTINE... 

628 C FIRST RENAME 

629 C 

630 C then CONTINUE REBUILDING THE MET 

631 CALL STATIC (JNET,JTRNS,JEV,JTR) 

63? C NON LOOK FOP THE BEGIN STATEMENT... 

633 I=TFINDN fl OHPtGIN ,JNET) 

63a lEfl.NE.O) GO TO 1600 

635 CALL ERRRRR(P,6HPG''iNE T,0) 

636 C 

637 1600 CONTINUE 

638 C MARK THE SOFTWARE 6EGTN EVENT 

639 JNFTfI,2)=l 

6ao return 

6a 1 END 

602 C 

603 C 

600 SUBROUTINE RSIMfNAME) 

605 BYTE TEMP 

606 DIMENSION TE'^PflO) 

607 COMHGN/NET/ NET ( ?55 , 0 ) , NTRNS T 255 , 3 ) , NFRE ( 999 , 2 ) , 

608 lNXTF,KTiME,NEV,NTR 

609 COMMON/SOFT/ J N£ T f 255 , 0 ) , J TRNS ( 255 , 3 ) , JE V , J T R 

650 COMMON/RST AbL/ IRS(90,3) 

651 C 

65? C THE REGUESTOR/SEPVEP INTERFACE TABLE 

653 C 

650 C [RS(M,n --) POINTED TO NAME OE SOFTWARE EVENT 

655 C REQUESTING SERVICE 

656 C IRSfM,2) start TIME OF REQUEST. 

657 C IRSfM,3) — ) HARDWARE UNIT NUMBER REQUIRED. 

65« C 

659 COMMON/CTRLR/ TMQOE , ICQ (?50 ) , ICQP TR 

660 C 
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661 c common block ctklr contains info regarding 

662 C HARDWARE REQUESTS, AMD EXISTS SO THAT THE U OF 

663 C REQUESTS HER MINOR CYCLE CAN LIMIT AS DESIRED. 

660 C REQUESTS STACKED IN ICO, THE QUEUE, AND SERVICED 

665 C AS POSSIPLE, A MAX OF IMOOE EVERY MINOR CYCLE. 

666 C 

667 C ENTER NAME IN THE TABLE, PLACE HN IN QUEUE, THEN 

668 C REMOVE SOFT TOKEN. (DO NOTHING IF SOFTEVENT 

669 c IS TYPE 0 If'HlCH IS A NULL EVENT FOR PRECEDENCE) 

670 C 

671 CALL GETNAM(MAME , TEMP) 

672 NUMBER = JN£T(IFlNDN(TEMp,.jr4ET) ,3) 

673 IF(NUMBER.EQ.O) RETURN 
670 C 

675 DO 1700 1 = 1 , <30 

676 IF( IRSCI , 1 ) .EQ.O) GO TO 1710 

677 1700 rONflNUE 

678 CALL f PRRRR ( 1 1 , AHRSIN, TEMP , 0) 

679 C 

680 1710 CONTINUE 

661 DU 1720 J=1 ,MEV 

682 IFCNET (J, 3) .EQ. NUMBER) GO TO 1730 

683 1720 COMIINUE 

680 CALL ERRRRR(9,aHRSTN,NAMp,0) 

685 1730 COMIINUE 

686 ICQPT RrICuP 1R + 1 

687 TF(ICQPTP.GT.250) CALL ERRRRP ( 1 1 , 1 OHRS I N (ICQ), 0,0) 

688 ICQ( ICQPTR)=.J 

689 J = TF INONdFMP, JNET ) 

690 JNFT(J,2)=0 

691 IRS( I , 1 )=NAME 

692 IRS(I,?)=KT1ME 

693 IRS( I , 3)=NUMPEP 

690 1700 FORMA I (5X, • ^program EVENT ',10A1,' REQUESTS Hvm’, 

695 1' SVCS ',115) 

696 WRITE( 7, 1 700) ( T EMP ( K ) , K = 1 , 1 0 ) , K T I me 

697 RETURN 

698 END 

699 C 

700 C 

701 SUBROUTINE R SOU I ( NUMP ER ) 

702 BYTE TEMP 

703 DIMENSION TEMPI 10) 

700 COMMON/NET/ NET ( 255 , 0 ) , NTRNS ( 255 , 3 ) , MERE ( 909 , 2 ) , 

705 lNXTF,KTiME,NFV,MTR 

706 COMMON/SOFT/ JME T ( 255 , 0 ) , J T R NS ( 255 , 3 ) , JE V , J I R 

707 COMMON/RST ABL/ 1RS(90,3) 

708 C 

709 C NEI TRANSITION NUMBER (HARDWARE) HAS COMPLETED, 

710 C SEE IE ITS TYPE IS .LT. 0 (A UNIT FINISH EVENT), 

711 C AND IF SO, SEE IF A SOFTWARE EVENT WAS EXECUTING. 

712 C IE SO, ON A FIFO BASIS, COMPLETE THE SOFIEVENT, 

713 C PRINT A MESSAGE, REPLACE THE TOKEN IN THE SOFTNET 

710 C AND CONTINUE. 

715 C 

716 IF(NET (NUMBER, 3) .GE.O) RETURN 

717 C 

718 1800 FORMAT (5X ,' *PROGRAM EVENT ',10A1,' COMPLETES ',115) 

719 .1 = 0 

720 K=10000 
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721 C 

722 DO IPIO 1=1,90 

723 TF r iPS ( 1 , 3) .ME. (NET (MUMBFR, 3) *-l ) ) GO TO 1810 

72« IFC1RS(I,2) .Gt.K) GO TO 1810 

725 J=T 

726 K=IRS(I,2) 

727 1810 COM TT NOE 

728 C 

729 IF(J.EO.O) RETURN 

730 C FOUND IT 

731 C MARK SOFTEVFNT, UMMARK HAPDEVENT 

73? CALL GF TNAV( IRS (J, 1 ), TEMP) 

733 K=TFTNDN(TEMP,JNE1) 

73a CALL GE TNA'MJNET CK , 1) , TEMP) 

735 lrjRTTE(7, 1 800) ( T EMP ( L ) , L= 1 , 1 0 ) , K T I ME 

736 JNET(K,2)=1 

737 NET ( number, 2 )=MET (NUMBER, 2 )-l 

738 IRvS(J,l)=0 

739 IRS(J,2)=0 

7a0 IRS ( J, 3)=0 

7al RETURN 

7a2 END 

7^3 C 
7HH C 

7U5 FUNCTION K SUF T ( I DUMM Y ) 

7a6 COMMON/RST ABL/ IR3(90,3) 

747 C 

748 C COUNT NUMBER OF ACTIVE PROCESSES IN TABLE 

749 C 

750 J=0 

751 DO 1900 T=1,9U 

752 TF( 1PS( I , 1 ) .NE.O) J=J+1 

753 1900 CONTINUE 
KSOFT=J 
RETURN 
END 



SUBROUTINE N AME I T ( T PO I N T , S TR I NG , KOUN T ) 



ENTER NAME OF EVENT OR TRANSITION 'STRING' 
INTO THE GENERAL NAME TABLE. RETURN A 
POINTER TO ITS ENTRY 'IPOINT'. 



BYTE NAMES, STRING, TBLANK 
COMMON/NAME1/NAMES(203, 10) ,NXTNAM 
DIMENSION STRINGMO) 

DATA NVTNAM/1/ 

DATA IPLANK/IH / 

ERASE TME ENTRY 
DO 1920 T=l,10 

774 1P20 NAMES (NXTN AM, I ) =TBL ANK 

775 C COPY IN THE DATA 

776 DO 1921 T=1, FOUNT 

777 1921 NAMES(NXTNAM, I)=STRING(I) 

77« C BUMP the pointer AND TEST FOR OVERFLOW. 

770 IPOIN r=NX TNA^' 

780 NXTNAM = NXTNAM+ 1 



754 

755 

756 

757 

758 

759 

760 

761 
76? 

763 

764 

765 

766 

767 

768 

769 

770 

771 

772 

773 



C 

C 

C 

C 

C 

C 

C 

C 

C 
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781 

78? 

78? 

78« 

785 

786 

787 

788 

789 

790 

791 
79? 
793 

79a 

795 

796 

797 

798 

799 

800 
801 
80? 
803 
809 

805 

806 

807 

808 

809 

810 
811 
81 ? 
813 
819 

815 

816 

817 

818 
819 
8?0 
«?1 
8 ?? 
8?3 
829 
8?5 
826 
8?7 
8?8 

829 

830 
831 
83? 
833 
839 

835 

836 

837 

838 
839 
890 



IF (NXTNAM.GT .?03) GO TO 19?? 

D9000 FOPiVAIC NAMFIT: I PO T N T , S I R i NG ’ , I 9 , 2 X , 1 A 1 0 ) 
D InRI IF (7 ,90 00 ) IPO INT , (STRING! I ) , 1 = 1 , 1 0) 

RETURN 

C GOT A PRUBLFH 

19?? CUNIInUE 

19?3 FORMA! (• **NAMF TABLF OVERFLOW DETECTED BY’, 

fFAlAL)') 



1990 

09000 

D 

C 

C 

C 



1' MAMET I. . 
WRITE (6, 19?5) 
CALL EXIT 
END 



1960 

C 

D9000 

D 



SUBROUTINE GE TN AM ( j PC I N I , S TR I NG ) 

GET THE NAME flO BYTE STRING) POINTED TO BY 
"IPOINT" and return IT IN "STRING" 

BYTE NAMES, STRING 

COMmon/NAME 1/NA|VES(?03, 10) ,NXTNAM 
niMENSTOM STRING(IO) 

DO 1990 1=1,10 
STPING(I)=NAmeS(TPOINT, I) 

FORMATC GFTNAM: I PO T N T , S T R I NG ’ , I 9 , 2 X , 1 A 1 0 ) 
WRITE(7,Q000) TPOINT,(STPING(I),I=1,10) 

WASN ' T THAT SIMRL E? 

RETURN 

END 



SUBROUTINE NAMINP( I POINT, NUMB) 

NAME IT FROM AN INPUT SCANNER WORD 
BYTE I WORD 

COMMON/SCAN/NIJMtiER, IWOPDf 15,10) 

BYTE TEMP 

DIMENSION TEMp(lO) 

DU I960 1=1,10 
TEMPI I )=I /.'CRD (NUMB, I) 

FORMAT!' NA^,T^\|P: NUMB, STRING ' , I 9 , ?X , 1 A 1 0 ) 
WRTTE(7,900U) NUMB, ( TEMp ( I ) , I = 1 , 1 0 ) 

CALL NAMFIT ( IPOIN I , TEMP, 1 0) 

RETURN 

END 

SUBROUTIME SCANR(LUNIT) 



FREE format input ROUTINE. READS AN 80 BYTE 
RECORD FROM LOGICAL UNIT "LUNIT" AND STORES UP 
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841 C 

842 C 
845 C 

844 C 

845 C 

846 C 

847 C 

848 C 

849 

850 

851 

852 

853 

854 

855 

856 

857 

858 

859 C 

860 
861 
862 

863 

864 C 

865 

866 C 

867 C 

868 C 

869 C 

870 

871 

872 C 

873 

874 

875 C 

876 

877 C 

878 

879 

880 
881 
882 

883 C 

884 

885 

886 

887 

888 

889 

890 C 

891 

892 C 

893 

894 

895 C 

896 

897 C 

898 C 

899 

900 



TO 15 blank delimited tokens (LEFT ADJUSTED) 

IN BYTE AKPAY "lUUPD’’. 

NUMERICAL values CAN BE REFORMATTED FROM BYTE 
STRINGS INTO INTEGER AND FLOATING POINT VALUES 
THRU THE SUBPOUriNES "XELOAT" AND "XINTGR". 



BYTE P'jORD, ISC , IBLANK 
COMimON/SCAM/NIJMBER, Il'.'ORDC 15,10) 

BYTE NFUFFR 

CQMMON/SCAMl /NBUFER (80 ) 

DATA ISC/l*-*;/ 

DATA I8LANK/1H / 

DATA NEOF/0/ 

DATA KLIME/0/ 

200 1 KLTNE = KLINEt 1 
2000 F0RMAT(80A1) 

BEGIN BY Reading a line of bo bytes... 

READfLUNI T ,20 0 0, END = 2 035, ERR = 2 035) (NBUFFRd ) , 

11=1 ,80) 

2002 FORMA I (X , 1 14, • - ',80A1) 

WRI TE ( 7, 20 02) KLINF , (NBIJFFP( I ) , 1 = 1 , 80) 

SET POINTER TO FIpST CHARACTER IN THE BUFFER 
IPOIMT = 1 

NOrt PROCESS THE FTRST 15 TOKENS DELIMLTED BY 
EITHER A BLANK (OP MULTIPLE BLANKS) OR A 
SEMICOLOli. 

DO 2025 NU^'’BER=1 , 15 
IFLAG=0 

SET 1W0P0(NUMBER,X)=IRLANK(SET WORD TO ALL BLANKS) 
DO 2005 1=1,10 
2005 Iv^jORD (NUMBER, I ) =TBLANK 

START SCAM OF LINE FROM POINTER ON, FIND NON-BLANK 
KOUNT=l 

"KUUNT" keeps track OF MO. OF CHAR. IN THE TOKEN 
DO 2015 KPOINT=IPOINT,80 

IF (NRUFFR (KPO IMT) .ME . IPLANK .ANO. NBUFFR (KPOINT ) 
l.NE.ISC) GO TO 2010 
IF ( IFLAG.EO.O) GO TO 2015 
TFdFLAG.EO.l ) GO TO 2020 

GUT SOMETHING, SO PROCESS IT.... 

2010 CONTINUE 
IFLAG=1 

IiAiORD (NUMBER ,KOUNT)=NBUFFR(KPOINT) 

KOUNT = KOUNT + 1 

TF(KOUNT.GT. 10) GO TP 2020 
2015 CONTINUE 

2020 CONTINUE „ 

END OF TOKEN FOUND, RESET SOME POINTERS 
IPOINT=KPOTNT + I 
TFdPOINT.GT.80) GO TO 2030 

2025 CONTINUE 

END OF BASIC TOKFN GETTING LOOP 

2030 NUMBFR=NUMeER-l 

IF (NUMBER .FQ .0 ) GO TP 200 1 
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901 IF (MATCHSC 1 , 'COI^^^EMT: ' ,8) .EQ. 1) GO TO 2001 

902 RETUPf'i 

903 2035 C06'TINUE 

9oa C END OF FILE HP I/O ERROR DETECTED 

905 2040 FORMAT!' EOF OR ERROR ON SCANNER INPUT FROM UNIT 

906 113) 

907 WRI TE(7,20aO) LUMT 

908 NEOF=NEOF+l 

909 IFfNEOF.GE.3) CALL EXIT 

910 NUMBER=0 

911 RETURN 

912 END 

913 C 

914 C 

915 SURROUTIME XFLO AT ( NwORD , FWORD ) 

916 C 

917 C CONVERT THE Ei'jTRY IN ARRAY IWORD (« NWORD) TO 

918 C standard FLOATING POINT REPRESENTATION, RETURN 

919 C IT AS "EWORD". 

920 C 

921 BYTE II/"ORD 

922 C OMMON /SC AN/ number , I WORD ! 1 5 , 1 0 ) 

923 C 

924 BYTE TSTRNG 

925 DIMENSION TSTPNGCIO) 

926 C 

927 C COPY STRING (TO ALLO^i COMPILER TO STORE THE ARRAY 

928 C HO.yEVER it I/'IANTS TO) 

929 DO 2045 T=1 , 1 0 

930 2045 TSTRNGf I) = IHORO(M'/jORO, T) 

931 C 

932 C DEFINE THE FORMATS: 

033 2050 format ( IF 1 0 .3) 

934 c DO it: 

935 DECODEf 10,2050, TSTRNG) FWORD 

936 RETURN 

937 END 

938 C 

939 C 

940 SUBROUTINE X INTGR ( NWORD , I V ALUE ) 

94 1 C 

9i(2 C CONVERT THF ENTRY IN "TWORD" TO INTEGER 

943 C RETURN IMTFGER "IVALUE" 

944 C 

945 BYTE IHORD 

946 common /SC AM /NUMBER, IWOPD( 15, 10) 

9a7 BYTE TSTRNG 

948 DIMEMSTOM TSTRNG(IO) 

949 byte IRLANK 

950 DATA IBLANK/IH / 

951 C 

952 C COPY THE STRING (SAME PROBLEM AS ABOVE) 

953 DO 2055 1=1,10 

954 KOUNT=I 

955 TSTRNG ( i ) = T/jORD (M/iORD, I ) 

956 IF ( I WORD (NWORD , I ) .EQ . IRLANK ) GO TO 2060 

957 C WE'VE FOUND TiiE END OF THE LINE 

958 2055 CUMTINUE 

959 2060 CONTINUE 

960 KUIINT = KOUNT- 1 



99 



oetrinet.ftn 



Pane 17 



Tue iMov 27 0o: 18:55 1979 



961 C 

962 20b5 FORM'il (1110) 

963 C 

960 DECODE (KnUM r , 20bS, TSTRNG) IVALUE 

<365 return 

966 END 

967 C 
9ti8 C 

9b9 FUNCTION MATCHS(MUVB, STRING, NCHAR) 

970 C 

971 C THIS FUNCIIOM OETERiMINFS IF SCANNER TOKEN 

972 C I/iPRD (NU^B ) MATCHES THE CHARACTERS IN "STRING" 

973 C A| least for the FIRST "NCHAR" CHARACTERS. 

970 C 

975 C IF there IS A ^ATCH, IT RETURNS THE INTEGER "1 

°76 C NU MAICH RETURNS "0". 

Q77 C 

97B BT^TE IWUPD 

97° COMMON/SCAN/MUMBER, INORDf 15, 10) 

980 BYTE STRING 

981 dimension STRING! 10) 

982 MATCHS=0 

983 C 

980 C test the STRINGS... 

985 no 2070 1=1 ,MCHAR 

986 TF(H''0RD(NUMP, I) .NE.STRING(I) ) RETURN 

987 2070 CONflNUE 

988 C 

989 C IF YOU GET HERE, THEY WERE THE SAME... 

°90 MATCHS=1 

991 RETURN 

992 END 

993 C 
°9 0 C 



995 SUBROUTINE E RRRRP ( K I ND , K A LLE R , M AME , M ARK ) 

996 CO'^MON/RRR/ '^SG(M) 

997 C M3G(N)=FATAL FLAG (l--)FATAL) 

998 BYTE KALLER,NAME 

99° DIMENSION K ALLER ( 1 0 ) , N AME ( 1 0 ) 

1000 MSG(1)=1 

1001 MSG(2)=1 

1002 MSG(3)=0 

1003 M3G(0)=0 

1000 MSG(S)=0 

1005 MSG(6)=0 

100b MSG(7)=0 

1007 MSG(8)=1 

1008 MSG(9)=1 

1009 MSG(10)=0 

1010 MSG(11)=1 

1011 C 

1012 2101 FORMAT (5X, 1 A?, 'ERPUR ',112,' DETECTED BY 

1013 1' MISSING SECT. BEGIN (FATAL) ',1A2) 

1010 2102 format (5X, 1 A2, 'ERROR ',112,' DETECTED BY 

1015 1’ SYMBOL table OVERFLOW (FATAL) ',1A2) 

1016 2103 format ( 5x , 1 A2, ' ERROR ',11?,' DETECTED BY 

1017 1' NAME DUPLICATION (IGNORED) *,1A2) 

1018 2104 FORMAT (5X, 1A2, 'ERROR ',112,' DETECTED BY 

1019 1,' ',10A1,' UNDEFINED ( T GMORED ) ' , 1 A2 ) 

1020 2105 FORMAT (5x , 1 A2 ,' ERROR ',112,' DETECTED BY 
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1 053 
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1073 
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1076 
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1' --SYNTAX ERR0P-- (TGNUREO) ',1A2) 

2106 F0RMAT(SX, 1A2, 'ERROP '/1I2/' DETECIEO BY ' 

1' DYNAMIC conflict •,10A1,1A2) 

2107 FORMAT (5X , 1 A2, • EVENT ',10A1,' MARKED 
I 1 A2) 

2108 F0RMAT(5X, 1 A2, ’FRPOP ’,112,’ DETECTED BY ’ 
1’ NO PEC-IN EVENT FOUND f SOF TNE T ) ’ , 1 A2 ) 

2109 F0RMAT(5X, 1A2, ’ERROR ’,112,’ DETECTED BY ’ 
1’ NON-EXIST. H'rt UNIT REQUESTED. ’,1A2) 

2110 F0RMAT(5X, 1A2, ’ERROR ’,112,’ DETECTED BY ’ 

1 t FRRUR-1 0 BAD-CALL-TO-ER ’ , 1 A2) 

2111 format (5X, IA2, 'ERROR ’,112,’ DETECTED BY ’ 
1’ R/S FABLE OVERFLOW (FATAL) ’,1A2) 

C 

KST AR=2H** 

C 

IF(K1ND.LT.1 .OR. KIND.OT.il) KIwD=10 
IF(KIND.EQ. 1) GO TO 2121 
IF(KIMD.EQ.2) GO TO 2122 
IF (K IND.EQ. 3 ) GO TO 2123 
IF(KIN0.£Q.4) GO TO 2124 
1F(KIND.EQ.5) go to 2125 
IF(KIHD.EQ.6) go to 2126 
IF(KIMD.EQ.7) go to 2127 
IF(KIN0.EQ.8) GO TO 2128 
IF(KIND.EQ.P) GO TO 212° 

IFCKIND.EQ.IO) GO TO 2130 
c then KIND=1 1 

WRITE (7, 21 I 1 ) kSTAR,KIND,KALLER,KSTAR 
IF(MSG(K1N0) .EQ.O) RETURN 
CALL EXIF 

2121 CONTINUE 

WRITEf7,2101J KSTAR,KTND,KALLER,KSTAR 
IF(MSG(KIND) .EQ.O) RETURN 
CALL EXIF 

2122 CONTINUE 

I'jRITEf 7,2102) KSTAR,KIMD,KALLER,kSTAR 
IF (MSG(KIND) .EQ.O) RETURN 
CALL EXIT 

2123 CONTINUE 

WRIT£(7,2103) KSTAR,KTND,KALLER,KSTAR 
IF(MSG(KIN0) .EQ.O) RETURN 
CALL EXIT 

2124 CONTINUE 

WRITE! 7,21 04) KS T AR , K I NO , K ALLER , N AME , KST AR 
IF(MSG(KIND) .EQ.O) RETURN 
CALL EXIF 

2125 CONTINUE 

WRITE (7,2105) KS T AR , K T ND , K ALLER , KS T AR 
IF(MSGCKIND) .EQ.O) RETURN 
CALL EXIF 
212b CONTINUE 

wRIT£(7,2106) KSTAR,KTND,KALLER,NAME,KSTAP 
IF (MSO (K IND) .EQ. 0) RETURN 
CALL FXII 

2127 CONTINUE 

WRITE (7, 2 107) K ST AR , K ALLER , MARK , KST AR 
IFC^SG(KIND) .EQ.O) RETURN 
call EXIT 

2128 continue 
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1 OPl 
1082 
1083 
108a 

1085 

1086 

1087 

1088 
1 089 

1090 

1091 
10^2 



k^RITtr7,2l08) KSTAR,KIND,KALLER,KSTAR 
IFCMSCrKINU) .EQ.01 RETURN 
CALL EXIT 

2129 COmiNUE 

vnRITE(7,2109) kSTAR,KINO,KALLER,KSTAR 
IF(MSr,(KlMO) .EQ.O) RETURN 
CALL EXIT 

2130 CONTINUE 

wRITE( 7,21 10) K?TAR,KTND,KALLER,KSTAR 
IP(f^Sn(KlMO) .EQ.O) RETURN 

call exit 

EMI) 
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